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Working  as  a  Team 


Back  in  May,  I  was  watching  the  Giro  d’ltalia  and  the  incredible  selfless  sacrifice  of 
American  cyclist  David  Zabriskie.  Zabriskie  was  arguably  one  of  the  strongest  rid¬ 
ers  in  the  peloton,  but  his  teammate  Andy  Schleck  was  even  stronger  and  stood  the 
best  chance  of  winning  the  race.  Despite  Zabriskie’s  chance  to  place  high  in  the  over¬ 
all  standings,  he  rode  to  help  his  teammate  conserve  energy  and  finish  the  race  second 
on  the  podium.  He  and  every  other  member  of  the  team  were  focused  on  the  perfor¬ 
mance  of  the  team,  not  the  performance  of  the  individual.  Effective  software  devel¬ 
opment  teams  need  to  have  the  same  mutual  commitment  to  work  together  towards  a  common 
goal.  This  level  of  mutual  commitment  doesn’t  happen  just  by  telling  people  that  we  want  them 
to  work  as  a  team.  Such  commitment  requires  several  enablers.  Many  of  the  articles  in  this 
month’s  addition  will  touch  upon  processes  for  creating  teams  that  truly  work  together.  I’d  like 
to  offer  my  brief  thoughts  on  four  key  enablers  for  creating  mutual  commitment  of  team  mem¬ 
bers. 

1.  Measure  the  project.  Over  and  over  again  I  see  proof  that  what  gets  measured  gets  done.  If 
you  focus  your  measurements  on  individuals,  then  individuals  will  perform.  If  you  focus  your 
measurements  on  project  performance,  the  project  will  perform.  Measures  should  focus  on 
what  is  important  to  the  customer  and  customers  don’t  care  about  the  performance  of  individ¬ 
uals.  We  all  have  internal  measures  and  targets,  but  leaders  should  insulate  their  teams  so  they 
can  focus  on  those  that  matter  to  their  customer. 

2.  Reward  project  performance  not  the  individual.  Although  easier  said  than  done,  espe¬ 
cially  in  the  public  sector,  it  is  the  performance  of  the  project  that  should  be  incentified  not  the 
performance  of  the  individual.  If  reward  incentives  focus  on  the  individual,  there  is  little  incen¬ 
tive  to  make  someone  else  look  good.  Project  incentives  will  help  individuals  focus  on  the  crit¬ 
ical  path,  not  just  their  piece  of  the  project. 

3.  Limit  specialization.  Rather  than  have  developers  narrowly  focused  on  one  specialty 
which  supports  many  projects,  utilize  people  broadly  to  avoid  bottle  necks  and  encourage  own¬ 
ership.  One  person  can  not  have  the  same  level  of  commitment  to  many  projects  as  the  team 
members  who  are  dedicated  to  one  project.  When  possible  it  is  better  to  have  them  committed 
to  one  or  two  teams  and  utilized  in  areas  outside  of  their  expertise  to  supplement  the  project. 

4.  Institute  Team  Member  Radio.  In  my  earlier  cycling  analogy,  each  team  member  is 
equipped  with  a  radio  that  is  in  contact  with  the  team  director  (and  other  coaches)  in  the  team 
car.  When  a  key  member  of  the  team  suffers  from  a  flat  or  has  a  mechanical  problem,  the  team 
director  signals  the  team  to  drop  back  to  help  their  team  member  rejoin  the  peloton.  The  direc¬ 
tor  also  keeps  close  watch  on  the  details  of  the  race.  The  director  warns  the  team  of  obstacles 
and  watches  for  threatening  tactics  from  the  other  teams.  The  team  members  themselves  are 
communicating  to  let  the  director  know  what  is  going  on  from  inside  the  peloton  that  can’t  be 
seen  from  the  team  car.  When  a  team  member  might  be  suffering  more  than  they  care  to  admit, 
his  team  members  can  communicate  information  back  to  the  director  so  she  can  decide  what  to 
do.  This  is  exactly  how  a  cohesive  software  development  team  should  work.  When  a  key  area  or 
key  member  of  a  software  team  gets  in  trouble  the  team  needs  to  come  to  the  rescue.  The  only 
way  for  the  team  to  avoid  obstacles,  capitalize  on  opportunities,  and  react  to  trouble  is  to  have 
constant  communication  up,  down,  and  through  the  team. 

Speaking  of  teamwork,  we  have  a  great  team  of  authors  lined  up  for  this  month.  Starting 
with  LTC  Nanette  Patton  and  Allan  Shechet,  they  address  achieving  project  success  in  Wisdom 
for  building  the  Project  Manager / Project  Sponsor  Relationship:  Partnership  for  Project  Success.  Jennifer 
Tucker  and  Hile  Rutledge  describe  the  necessity  of  maximizing  team  performance  in  Shaping 
Motivation  and  Lmotion  in  Technology  Teams,  and  Kasey  Thompson  and  Tim  Border  teach  managers 
to  build  more  efficient  teams  in  their  article  The  Gauge  That  Pays:  Project  Navigation  and  Team 
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Wisdom  for  Building  the  Project  Manager/Project  Sponsor 
Relationship:  Partnership  for  Project  Success 


LTC  Nanette  Patton  Allan  Shechet 

Office  of  the  Surgeon  General  Savvy  Services  Incorporated 

The  project  sponsor  can  promote  information  technology  (IT)  project  success  in  several  ways,  yet  many  projects  either  have 
no  formally  designated  project  sponsor  or  the  project  sponsor  is  confused  about  his /  her  role.  The  project  sponsor's  role  tra¬ 
ditionally  includes  project  approval,  funding,  and  staffing,  but  can  include  much  more.  The  project  sponsor  is  sometimes 
called  the  champion  of  the  project  or  the  key  stakeholder  of  the  project.  Because  the  role  of  the  project  sponsor  sometimes 
overlaps  with  the  project  manager's  role,  confusion  can  arise.  This  article  discusses  conventional  roles  and  responsibilities  of 
the  project  sponsor  and  then  discusses  strategies  a  project  manager  can  employ  to  define  boundaries  to  reduce  role  confusion 
and  promote  partnership  to  facilitate  project  success. 


What  is  the  role  of  the  project  spon¬ 
sor?  Projects  fail  for  a  plethora  of 
reasons.  One  of  the  most  common  rea¬ 
sons  for  project  failure  is  lack  of  project 
management  discipline.  Another  which  is 
much  harder  to  rectify  is  cultural  resis¬ 
tance  to  change  [1].  These  reasons  identi¬ 
fy  the  point  of  demarcation  between  the 
project  manager  and  the  project  sponsor. 
The  project  manager  runs  the  project  on 
a  day-to-day  basis  to  produce  a  solution 
to  a  business  problem,  and  the  project 
sponsor  manages  the  organizational  cul¬ 
ture  to  ensure  it  is  ready  to  receive, 
accept,  and  implement  that  solution.  If 
success  is  about  getting  results,  then  the 
role  of  the  project  sponsor  —  in  the  sim¬ 
plest  terms  —  is  to  help  the  project  man¬ 
ager  ensure  the  project  achieves  success 
through  desired  results. 

Thomsett  International  has  reviewed 
more  than  20  major  projects  that  were  in 
the  process  of  failing  or  had  failed.  They 
did  these  reviews  not  as  an  academic 
exercise  or  a  controlled  experiment,  but 
rather  these  reviews  were  undertaken  in 
the  heat  of  the  battle.  In  every  one  of  the  20 
major  failed  projects,  lack  of  an  effective 
sponsor  was  a  common  deficiency.  As 
one  project  manager  recently  put  it:  To 
manage  a  project  without  an  effective  executive 
sponsor  is  to  visit  hell  on  Earth  [2] . 

If  you  have  ever  been  a  project  man¬ 
ager,  then  perhaps  you  have  come  to  real¬ 
ize  the  limitations  of  your  influence 
because  no  matter  how  well  trained  or 
experienced  you  may  be,  corporate  objec¬ 
tives  associated  with  your  project  will 
never  be  achieved  if  there  is  not  someone 
leading  and  directing  the  business 
change.  Back  in  1515  when  he  published 
“The  Prince,”  Nicolo  Machiavelli  said  the 
following: 

And  it  ought  to  be  remembered 


that  there  is  nothing  more  difficult 
to  take  in  hand,  more  perilous  to 
conduct,  or  more  uncertain  in  its  2. 
success,  than  to  take  the  lead  in 
the  introduction  of  a  new  order  of 
things.  Because  the  innovator  has 
for  enemies  all  those  who  have 
done  well  under  the  old  condi¬ 
tions,  and  lukewarm  defenders  in 
those  who  may  do  well  under  the 
new.  This  coolness  arises  partly 
from  fear  of  the  opponents,  who 
have  the  laws  on  their  side,  and 
partly  from  the  incredulity  of 
men,  who  do  not  readily  believe  in 
new  things  until  they  have  had  a 
long  experience  of  them.  Thus  it 
happens  that  whenever  those  who 
are  hostile  have  the  opportunity  to 
attack,  they  do  it  like  partisans, 
whilst  the  others  defend  luke¬ 
warmly,  in  such  wise  that  the 
prince  is  endangered  along  with 
them.  [3] 

The  perils  associated  with  creating  a 
new  order  of  things  are  just  as  true  today  as 
they  were  back  in  Machiavelli’s  day.  And 
this  is  where  the  project  sponsor  comes  in 
to  assist  the  project  manager  in  the  shared 
responsibility  of  delivering  both  project 
deliverables  and  project  outcomes. 

So  what  does  managing  the  culture 
entail?  Neil  Love  and  Joan  Brant-Love 
define  the  project  sponsor’s  role  as  men¬ 
tor,  catalyst,  cheerleader,  barrier  buster, 
boundary  manager,  and  senior  manage¬ 
ment  liaison  [4] . 

1.  Mentor 

•  Increases  the  confidence  of  the 
project  manager. 

•  Helps  the  project  manager  under¬ 
stand  the  full  business  context  of 
project  decisions. 

•  Improves  the  project  manager’s 


leadership  and  problem-solving 
skills. 

Catalyst 

•  Stimulates  the  thinking  and  per¬ 
spectives  of  the  project  manager. 

•  Challenges  assumptions. 

•  Plays  devil's  advocate  to  help  the  pro¬ 
ject  manager  see  more  options/ 
reactions  and  raises  the  level  of 
thinking  of  the  project  manager. 

3.  Cheerleader 

•  Helps  the  project  manager  and 
others  stay  motivated  and  deal  with 
team  issues. 

•  Occasionally  directly  helps  the 
team  members  stay  motivated 
through  pep  talks  and  celebrations. 

•  Reminds  the  project  manager  and 
the  team  of  the  importance  of  the 
mission. 

4.  Barrier  Buster 

•  Knocks  down  barriers  that  are 
beyond  the  control  of  the  project 
manager  or  project  team. 

•  Barriers  can  include  non- support¬ 
ive  senior  managers  and  managers 
of  team  members,  resource  prob¬ 
lems,  team  member  availability 
problems,  or  lack  of  tools/equip¬ 
ment/  facilities/ software  needed  by 
the  team. 

5.  Boundary  Manager 

•  Keeps  executives,  managers,  and 
professionals  from  meddling  or 
interfering  with  the  team’s 
progress. 

•  Protects  the  team  from  unneces¬ 
sary  interactions  with  others  or 
unnecessary  reporting  to  others. 

•  Lets  the  team  perform  within  the 
boundaries  of  the  agreed-to  team 
mission  and  contract. 

6.  Senior  Management  Liaison 

•  Before  establishing  a  team,  the 
project  sponsor  briefs  the  organi- 
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Figure  1:  The  de  Bono  Group's  Six  Thinking  Hats  Topics  [9] 


nation’s  senior  leadership  group  on 
the  planned  team’s  mission,  desired 
team  members,  and  any  constraints 
on  the  project. 

•  As  the  team  moves  through  the 
project  life  cycle,  the  project  spon¬ 
sor  periodically  communicates  to 
management  the  team’s  progress  to 
date,  and  asks  for  help  on  issues 
beyond  the  control  or  influence  of 
the  project  sponsor. 

Breaking  it  down  further,  responsibili¬ 
ties  of  the  project  sponsor  can  include  the 
following: 

•  Ensuring  the  project  manager  and  the 
team  are  aligned  to  a  common  purpose. 

•  Providing  guidance  for  key  business 
strategies. 

•  Empowering  the  project  manager. 

•  Championing  the  project  and  the 
team. 

•  Formally  managing  the  project’s  scope. 

•  Approving  plans,  schedules,  and  bud¬ 
gets. 

•  Ensuring  sustained  buy-in. 

•  Clearing  roadblocks. 

•  Ensuring  timely  availability  of 
resources. 

•  Reviewing  the  project’s  progress. 

•  Ensuring  that  project  benefits  are  real¬ 
ized. 

•  Leading  the  functionals  through  busi¬ 
ness  process  re-engineering. 

So,  another  way  of  looking  at  the  divi¬ 
sion  of  role  and  responsibilities  between 
the  project  manager  and  the  project  spon¬ 
sor  is  the  project  sponsor  plays  a  more 
strategic  role  helping  the  team  and  the  rest 
of  the  organization  understand  how  the 
project  supports  the  strategic  plan  of  the 
organization.  The  project  manager  plays  a 
more  tactical  role  and  is  responsible  for 
the  day-to-day  progress  of  the  project. 

What  Can  the  Project 
Manager  Do  to  Make 
Sponsorship  Work? 

Technology  pull  or  technology  push  cre¬ 


ates  different  conditions  for  project  ini¬ 
tiation  and  consequently  the  staffing  of 
the  project.  In  the  technology  pull  sce¬ 
nario,  it  is  more  likely  the  project  spon¬ 
sor  will  manifest  prior  to  the  project 
manager.  As  the  project  and  project 
goals  evolve,  the  project  manager  will 
have  to  assess  whether  or  not  that  initial 
person  driving  the  adoption  of  the 
technology  remains  the  best  candidate 
for  continued  project  success.  In  the 
technology  push  scenario,  the  project 
manager  will  more  likely  appear  before 
the  sponsor.  This  scenario  affords  the 
opportunity  for  the  project  manager  to 
work  with  the  organization’s  leadership 
to  help  identify  and  select  the  sponsor. 

The  person  identified  as  the  sponsor 
must  be  high  enough  in  the  organiza¬ 
tional  hierarchy  to  have  organizational 
authority  commensurate  with  the  scope 
of  the  project.  Conversely,  the  project 
sponsor  cannot  be  too  high  in  the  orga¬ 
nization  such  that  he  or  she  does  not 
have  sufficient  time  to  dedicate  to  the 
project  or  is  too  far  removed  from  the 
scope  and  objectives  of  the  project  to 
be  effective  in  giving  direction.  The  log¬ 
ical  project  sponsor  is  the  person  in  the 
organization  who  both  wants  the  pro¬ 
ject  accomplished  and  has  responsibili¬ 
ty  for  all  of  the  organizational  units 
affected.  In  short,  the  sponsor  is  the 
person  who  can  make  it  happen. 

Further  complicating  matters  is  the 
possibility  that  the  project  sponsor  and 
manager  may  come  from  different 
organizations.  For  example,  project 
managers  for  United  States  Army 
Medical  Command  (USAMEDCOM) 
enterprise-wide  projects  are  assigned 
from  the  U.S.  Army  Medical 
Information  Technology  Center 
(USAMITC)  and  the  project  sponsor 
(functional  proponent)  is  typically 
assigned  from  another  command  with¬ 
in  the  USAMEDCOM  where  the  func¬ 
tional  expertise  resides.  This  dynamic 


can  lead  to  conflict  from  differing  cul¬ 
tures  and  loyalties  that  will  have  to  be 
reconciled. 

Once  the  project  sponsor  is  identi¬ 
fied  and  teamed  with  a  project  manag¬ 
er,  the  project  manager  needs  to  com¬ 
mit  to  taking  responsibility  for  the  qual¬ 
ity  and  productivity  of  the  manager/ 
sponsor  relationship  to  meet  project 
accountabilities  [5].  Developing  a  good 
manager/ sponsor  team  is  not  an  acci¬ 
dent;  rather,  it  is  a  function  of  the  man¬ 
ager’s  relationship  behavior  (the  man¬ 
ner  in  which  the  manager  relates  to  the 
sponsor,  which  in  turn  creates  a 
response  that  sets  the  tone  of  the  rela¬ 
tionship).  The  project  manager  must 
take  personal  responsibility  for  the 
quality  of  that  relationship,  never  wait¬ 
ing  for  senior  leadership  to  notice  and 
act  on  a  situation  that  needs  attention. 
To  do  that,  the  project  manager  must 
do  the  following: 

•  Recognize  individuals  are  not  pas¬ 
sive  recipients  in  the  team/partner¬ 
ship  experience,  that  individual 
behavior  shapes  every  team,  and 
that  the  individual  affects  the  team 
at  least  as  much  as  the  team  affects 
the  individual. 

•  Acknowledge  that  not  attending  to 
team  performance  and  the  project 
manager/ sponsor  relationship  is  a 
choice  and  puts  the  project  manager 
at  the  mercy  of  chance. 

•  Accept  in  the  scenario  of  project 
sponsor/manager  shared  responsi¬ 
bility  that  the  quality  and  productiv¬ 
ity  of  that  relationship  is  worthy  of 
focus. 

•  Learn  what  behaviors  and  processes 
lead  to  a  successful  partnership  and 
exhibit  them  [5]. 

Conversely,  the  project  sponsor 
must  take  an  active  role  and  may  be 
required  to  back  that  role  up  with  trav¬ 
el,  late  nights,  and  presentations  to 
stakeholders.  First  time  sponsors  typi- 


November  2007 


www.stsc.hill.af.mil  5 


Working  as  a  Team 


cally  underestimate  the  amount  of  time 
and  commitment  it  takes,  and  the  sea¬ 
soned  project  manager  will  be  prepared 
with  estimates  and  confirmation  from 
other  project  sponsors.  Project  man¬ 
agers,  more  typically  devoted  to  a  single 
project,  must  take  into  consideration 
that  the  sponsor  may  be  covering  mul¬ 
tiple  projects.  However,  there  is  an 
upper  limit  for  the  project  sponsor.  If 
the  sponsor  covers  too  many  projects  at 
once,  effectiveness  can  become  diluted. 

Dr.  Ted  Weston,  Jr.,  Professor  in  the 
Computer  Information  Systems  De¬ 
partment  of  Colorado  State  Univer¬ 
sity’s  College  of  Business,  cannot 
overemphasize  the  importance  of  a  sin¬ 
gle  project  sponsor: 

Without  an  empowered  sponsor, 
the  project  is  essentially  DOA 
[dead  on  arrival].  In  order  to  get 
the  project  support  needed,  the 
sponsor  must  be  a  part  of  top 
management  and  have  the  ear  of 
top  management.  The  vision  of 
the  sponsor  (and  there  must  be 
one)  and  the  vision/expectations 
of  the  stakeholders  must  be  essen¬ 
tially  one  and  the  same.  The  project 
steering  committee,  by  whatever 
name,  must  be  supportive  of  both 
the  sponsor  and  the  project’s  goals. 

If  wishy-washy  —  STOP.  If  func¬ 
tional  area  or  sponsor  is  not 
respected,  the  project  is  off  to  a 
bad  start.  Furthermore,  the  spon¬ 
sor’s  commitment  to  the  project 
must  be  real  and  not  lip-service.  If 
you  cannot  sense  the  fire  in  the  belly 
of  the  sponsor  —  stop!  The  spon¬ 
sor  must  actively  champion  the 
project  and  communicate  the  sense 
of  project  urgency.  No  urgency  — 
the  project  is  again  in  trouble.  [6] 

Both  the  project  manager  and  spon¬ 
sor  must  recognize  what  effective  spon¬ 
sorship  looks  like.  Project  sponsorship 
is  far  more  than  saying,  here's  a  bunch  of 
resources,  tell  me  when  we’re  better.  Many 
project  sponsors  have  little  understand¬ 
ing  of  the  role,  and  it  may  fall  to  the 
project  manager  to  educate  and  coach 
them  —  on  both  the  tasks  and  the  time 
commitment. 

Some  organizations  offer  some  kind 
of  training  for  the  project  sponsor.  For 
example,  the  Army  Medical  Depart¬ 
ment  (AMEDD)  offers  the  Health 
Systems  Functional  Proponent  Course 
(HSFPC)  to  help  prepare  project  spon¬ 
sors  for  the  demands  of  the  role  [7]. 
Dr.  Barbara  Erickson,  one  of  the  cre¬ 


ators  of  the  HSFPC,  said  the  following: 

The  HSFPC  was  established  in 
response  to  the  education  and 
training  assessment  resulting 
from  the  Task  Force  Mercury 
Reengineering  Study  of  1996, 
which  was  commissioned  by  The 
Army  Surgeon  General  (then 
Major  General  James  Peake). 
The  task  force  identified  Infor¬ 
mation  Management  (IM) /In¬ 
formation  Technology  (IT) 
requirements  and  gaps.  Subse¬ 
quently,  Information  Manage- 

“Both  the  project 
manager  and  sponsor 
must  recognize  what 
effective  sponsorship 
looks  like.  Project 
sponsorship  is  far  more 
than  saying,  ‘ here's  a 
bunch  of  resources,  tell 
me  when  we’re  better ! 

...  it  may  fall  to  the 
project  manager  to 
educate  and  coach 
them  ...” 


ment/Information  Technology 
Subject  Matter  Experts  and  train¬ 
ing  experts  worked  together  to 
identify  the  critical  tasks,  skills, 
and  knowledge  needed  to  meet 
deficiencies  that  could  be  correct¬ 
ed  by  education  and  training  and 
thus  the  HSFPC  was  born  to 
serve  as  the  missing  link  between 
the  functional  (or  business 
process)  requirements  and  the 
technical  realization  of  them.  [7] 

USAMITC  is  the  AMEDD’s  execu¬ 
tion,  acquisition,  and  materiel  develop¬ 
ment  arm  for  information  technology. 
In  this  role,  USAMITC  houses  the  pro¬ 
ject  managers  for  the  AMEDD  enter¬ 
prise  IT  project  who  partner  with  the 
functional  proponents  (aka  project 
sponsors)  for  the  delivery  of  a  new  IT 


system  or  service.  When  LTC  Patton 
was  the  Chief  Information  Officer 
(CIO)  at  USAMITC,  she  made  a  point 
of  personally  presenting  at  the  HSFPC. 
Prior  to  her  arrival,  the  block  of  instruc¬ 
tion  on  USAMITC  and  its  services  was 
taught  by  a  USAMITC  marketing  spe¬ 
cialist.  Mission  success  for  USAMITC  is 
in  part  derived  from  successful  partner¬ 
ships  between  the  USAMITC  project 
directors  and  the  functional  proponents. 
Knowing  the  graduates  of  the  course 
would  be  paired  with  project  managers 
from  USAMITC,  she  decided  advocating 
and  facilitating  this  relationship  was  too 
important  to  delegate  to  a  marketing  spe¬ 
cialist.  Thus,  project  managers  should 
enlist  their  organization’s  IT  leadership  in 
promoting  successful  partnerships 
between  project  sponsors  and  managers. 

If  the  organization  is  less  formal  in 
training  project  sponsors,  the  project 
manager  can  refer  the  sponsor  to  other 
reading  material.  For  example,  the 
California  Office  of  Systems  Integra¬ 
tion  posts  its  best  practices  on  its  public 
Web  site,  which  includes  a  listing  of  the 
roles  and  responsibilities  of  the  project 
sponsor  in  their  work  environment  [8]. 

Negotiating  the  Sponsor 
Agreement 

While  the  roles  and  responsibilities 
cited  earlier  are  commonly  associated 
with  the  project  sponsor,  each  project  is 
different  and  there  is  always  room  for 
negotiation.  Depending  on  the  situa¬ 
tion  at  hand  and  the  knowledge,  skills, 
and  abilities  of  the  people  involved, 
roles  can  be  assigned  differently  (see 
Figure  1,  page  5).  Each  person  is  differ¬ 
ent.  Each  person  has  a  unique  set  of 
talents,  a  unique  pattern  of  behaviors, 
passions,  and  yearnings.  Each  person’s 
pattern  of  talents  is  enduring  and  resis¬ 
tant  to  change.  Each  person  has  a 
unique  destiny.  The  goal  is  to  help  each  per¬ 
son  become  more  of  who  he  already  is  to 
maximize  benefit  for  the  manager/ 
sponsor  partnership  and  the  project  team 
[9].  Thus,  the  project  manager  can  and 
should  work  with  the  sponsor  to  develop 
a  sponsorship  agreement,  clarifying  the 
sponsor’s  role  and  specific  responsibili¬ 
ties  and  identifying  role  boundaries 
between  the  sponsor  and  the  project 
manager,  thereby  reducing  the  confusion 
created  by  the  occasional  overlap  of  the 
roles  and  leveraging  individual  strengths 
to  promote  project  success. 

Even  the  most  educated  and  experi¬ 
enced  managers  occasionally  argue  or 
misunderstand  each  other;  however,  the 
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Title 

Role 

Project 

Manager 

The  person  responsible  for  developing,  in  conjunction  with  the  project  sponsor, 
a  definition  of  the  project.  The  project  manager  then  ensures  that  the  project  is 
delivered  on  time,  to  budget,  and  to  the  required  quality  standard  (within  agreed 
specifications).  He/she  ensures  the  proper  allocation  of  resources  within  the 
project,  and  manages  relationships  with  a  wide  range  of  groups  (including  all 
project  contributors).  The  project  manager  is  also  responsible  for  managing  the 
work  of  consultants,  allocating  and  utilizing  resources  in  an  efficient  manner, 
and  maintaining  a  cooperative,  motivated,  and  successful  team. 

Responsibilities 

•  Managir 

•  Recruiti 

•  Managir 

•  Using  d 
o  Deve 
o  Man« 
o  Recc 
o  Resc 
o  Man< 
o  Mon 
o  Prov 
o  Man« 
o  Prov 

man* 

o  Man* 
o  Man* 
o  Prov 

•  Working 

•  Providin 

•  Identifyi 

•  Acceptir 

ig  and  leading  the  project  team, 
ng  project  staff  and  consultants. 

ig  coordination  of  the  partners  and  working  groups  engaged  in  project  work, 
etailed  project  planning  and  control,  including  the  following: 

Hoping  and  maintaining  a  detailed  project  plan. 

aging  project  deliverables  in  line  with  the  project  plan. 

jrding  and  managing  project  issues  and  escalating  where  necessary. 

)lving  cross-functional  issues  at  project  level. 

aging  project  scope  and  change  control  and  escalating  issues  where  necessary, 
toring  project  progress  and  performance, 
ding  status  reports  to  the  project  sponsor, 
aging  project  training  within  the  defined  budget. 

ding  liaison  with,  and  updates  progress  to,  project  steering  board/senior 
agement. 

aging  project  evaluation  and  dissemination  activities, 
aging  consultancy  input  within  the  defined  budget, 
ding  final  approval  of  the  design  specification, 
closely  with  users  to  ensure  the  project  meets  business  needs, 
g  a  definition  and  management  of  the  user  acceptance  testing  program, 
ng  user  training  needs  and  devising  and  managing  user  training  programs, 
ig  ultimate  authority  and  responsibility  for  project  outputs/deliverables. 

Title 

Role 

Project 

Sponsor 

The  person  who  commissions  others  to  deliver  the  project  and  champions  the 
cause  throughout  the  project.  Sponsors  will  normally  be  a  senior  member  of 
staff  with  a  relevant  area  of  responsibility  that  will  be  affected  by  the  outcome 
of  the  project.  They  are  involved  from  the  start  of  the  project,  including 
defining  the  project  in  conjunction  with  the  project  manager.  Once  the  project 
has  been  launched,  they  should  ensure  that  it  is  actively  reviewed.  The  project 
sponsor  is  usually  the  one  who  has  to  negotiate  a  path  through  the  tricky 
diplomatic  areas  of  the  project. 

Responsibilities 

•  Acts  as  champion  of  the  project,  ensuring  it  is  adequately  resourced  for  success. 

•  Ensures  the  timely  availability  of  these  essential  project  resources. 

•  Develops  and  communicates  a  vision  and  direction. 

•  Sponsors  the  communications  program;  communicates  the  program’s  goals  and  relates 
them  to  the  strategic  goals  and  objectives  of  the  organization  as  a  whole. 

•  Behaves  congruently  and  provides  a  consistent  message. 

•  Promotes  participation  and  inclusiveness  particularly  within  the  business  unit  in  which 
the  solution  will  be  implemented  and  assists  the  project  manager  in  promoting  this  within 
the  project  team. 

•  Gets  things  done  through  commitment  rather  than  control. 

•  Ensures  resolution  of  issues  escalated  by  the  project  manager  or  the  project  board. 

•  Makes  key  organization/commercial/business  decisions  for  the  project. 

•  Approves  the  budget  and  decides  tolerances;  recommends  killing  the  project  if 
appropriate. 

•  Leads  the  project  steering  board. 

•  Accepts  authority  and  responsibility  for  achieving  the  desired  business  outcomes 
derived  from  the  project. 

•  Is  accountable  for  the  timely  delivery  of  planned  benefits  associated  with  the  project. 

This  template  is  protected  by  the  Creative  Commons  Law  and  distributed  by  the  Joint  Information  Systems 
Committee  (JISC)  infoNet,  an  advisory  service  of  the  JISC  at  <www.jiscinfonet.ac.uk/lnfoKits>. 

Table  1 :  Negotiation  Process  Standard  Template 


probability  of  this  occurring  can  be 
minimized  by  laying  out  in  writing  the 
roles  and  responsibilities  of  the  project 
sponsor.  Documenting  delineated  roles 
and  responsibilities  is  particularly 
important  when  sponsorship  has  been 
delegated  to  an  acting  sponsor  —  some 
responsibilities  may  be  delegated  and 
others  may  remain  with  the  logical 
(original)  sponsor. 

The  entire  project  team  must  agree 
on  both  the  unique  and  shared  respon¬ 
sibilities  of  the  project  sponsor  and 
project  manager  based  on  what  the 
organization  and  project  team  agree  is 
important  and  feasible. 

Table  1  represents  a  standard  tem¬ 
plate  the  team  can  use  to  start  the  nego¬ 
tiation  process  [10,  11]. 

As  the  project  progresses,  the  pro¬ 
ject  manager  can  take  specific  steps  to 
keep  the  sponsor  involved  throughout 
the  life  of  the  project.  Again,  knowing 
what  the  sponsor  should  be  doing  and 
clearly  stating  those  expectations  is  pri¬ 
mary.  The  project  manager  can  facili¬ 
tate  sponsor  involvement  in  the  follow¬ 
ing  ways: 

•  As  the  project  moves  from  one 
phase  to  another,  discuss  with  the 
sponsor  what  to  expect  and  what 
questions  he/she  should  be  con¬ 
cerned  with. 

•  When  deliverables  are  submitted  for 
review,  indicate  what  kind  of  feed¬ 
back  is  needed. 

•  Involve  the  sponsor  in  the  prepara¬ 
tions  for  major  project  reviews, 
emphasizing  decisions  required  for 
progress. 

•  Inform  the  sponsor  promptly  of 
issues  needing  sponsorship  resolu¬ 
tion,  providing  background,  pros / 
cons,  and  recommendations  (see 
Table  2,  next  page). 

Real-Life  Applications 

Approaching  the  project  manager/ 
sponsor  relationship  as  a  true  partner¬ 
ship,  the  project  manager  and  project 
sponsor  can  divide  specific  roles  given 
the  general  guidelines  provided  accord¬ 
ing  to  each  partner’s  strengths  and  non¬ 
strengths.  For  example,  back  in  2000, 
USAMITC  was  embarking  on  its  imple¬ 
mentation  of  PlanView,  an  enterprise 
project  management  and  human 
resource  planning  tool.  Operation  of 
the  tool  requires  employees  to  submit 
timesheets  in  which  they  record  their 
time  against  tasks  associated  with  pro¬ 
ject  work  breakdown  schedules.  Initially 
the  assigned  project  manager  worked 
alone  without  the  help  of  a  project 


sponsor  to  facilitate  implementation. 
However,  that  arrangement  did  not 
produce  the  desired  results  as  the 
implementation  was  not  adequately 
progressing  for  the  satisfaction  of  the 
commander.  The  commander  decided 
to  assign  one  of  the  division  chiefs  as 


the  new  project  manager. 

While  this  division  chief  had  the 
title  of  project  leader ,  in  reality  she 
assumed  the  role  of  project  sponsor 
and  she  partnered  with  the  previous 
project  leader,  delegating  the  traditional 
day-to-day  roles  of  the  project  manager 
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Project  Phase 

Concerns 

Initiation 

•  Why  is  this  project  needed?  What’s  the  business  problem  being 
solved  or  the  opportunity  to  be  seized?  How  does  the  project  support 
our  corporate  goals? 

•  Do  we  have  a  long-term  vision  and  investment  strategy  in  place? 

•  From  the  organizational  perspective:  What  are  the  objectives?  What 
will  the  end  result  look  like? 

•  From  the  employee  perspective:  What  are  the  benefits?  How  will  life 
be  better  when  the  project  is  over? 

•  How  will  we  measure  success?  What  is  our  baseline?  What  is  our 
target? 

•  What  areas  of  the  organization  will  be  affected?  In  what  ways? 

•  What  are  the  constraints  -  in  time,  in  money,  in  quality? 

•  What  can  realistically  be  achieved  within  those  constraints? 

•  Should  we  proceed? 

Planning 

•  Who  needs  to  be  involved?  And  how?  Are  they  adequately  trained? 

•  What  are  the  boundaries  or  scope  of  the  project? 

•  Roughly  how  much  will  it  cost  and  how  long  will  it  take? 

•  What  are  the  risks?  Can  they  be  managed? 

•  Do  we  have  metrics  and  processes  in  place  to  promote  project 
success?  Do  we  have  systems  in  place  to  generate  quantifiable  data 
and  demonstrable  knowledge  to  create  go/no-go  decisions? 

•  Is  the  team  incentivized  on  forward-looking  measures? 

•  Have  we  assembled  the  right  team?  Are  team  members  aligned  to  a 
shared  purpose? 

•  Should  we  proceed? 

Execution 

•  Are  we  accomplishing  what  we  planned  to  accomplish?  Within  the 
planned  time  frame?  With  the  planned  resources?  Within  budget? 

•  Is  there  anything  1  can  do  to  facilitate  the  team’s  work? 

•  Are  we  getting  the  cooperation  we  need  from  the  business  units? 

•  What  can  1  do  to  remove  obstacles  and  promote  the  provision  of  the 
right  level  of  support  so  the  project  manager  has  a  clear  path  for 
project  execution? 

•  Does  senior  leadership  understand  their  role  and  responsibilities  in  IT 
project  management  process?  What  can  1  do  to  facilitate 
understanding? 

Control 

•  Are  plans  in  place  to  measure  the  predicted  benefits? 

•  Have  we  integrated  cost,  project  control,  and  knowledge 
management? 

Closing 

•  Did  we  accomplish  what  we  planned  to  accomplish?  Within  the 
planned  time  frame?  With  the  planned  resources?  Within  budget? 

•  How  did  we  perform  based  on  our  success  criteria? 

•  What  lessons  did  we  learn? 

•  What  remains  to  be  done? 

Table  2:  Sponsor  Concerns  by  Project  Phase  [12,  13] 


to  the  old  project  leader  who  remained 
part  of  the  project  team.  The  previous 
leader  became  the  technical  lead  and  she 
became  the  functional  lead  handling  the 
business  process  reengineering,  training, 
and  project  promotion.  This  arrange¬ 
ment  leveraged  each  other’s  experience, 
power  position,  and  strengths. 

With  a  partnership  established  and 
the  roles  clearly  delineated  between  the 
technical  lead  and  the  functional  lead, 
she  set  about  to  expedite  implementation 
and  user  adoption  of  the  system,  focus¬ 
ing  on  the  desired  business  outcomes  of 
the  commander  as  a  project  sponsor  is 
expected  to  do.  To  those  ends,  she  devel¬ 
oped  a  metrics  program  to  direct  time 
and  energy  to  activities  that  would  hasten 
project  success.  Meanwhile,  the  technical 
lead  focused  on  implementing  software 
updates  and  upgrades,  pushing  the  soft¬ 
ware  to  the  user  base  and  server  manage¬ 


ment.  Initially,  each  week  in  the  com¬ 
mander’s  staff  meeting  with  the  division 
chiefs,  the  functional  lead  would  report 
by  division  the  percentage  of  staff  mem¬ 
bers  completing  their  timesheets  by  the 
designated  deadline.  If  the  division  did 
not  meet  a  certain  percentage,  they  were 
labeled  red.  She  continued  to  focus  on 
this  metric  until  it  was  mostly  green  across 
the  board  and  then  she  changed  the  key 
metric. 

As  a  project  management  organiza¬ 
tion,  the  USAMITC  leadership  had  to 
ensure  people  were  devoting  most  of 
their  time  to  project  work  rather  than 
overhead  functions  in  order  to  demon¬ 
strate  value  to  the  AMEDD  enterprise. 
While  she  continued  to  report  on 
timesheet  reporting  compliance  as  a  con¬ 
trol  measure,  she  now  diverted  the  atten¬ 
tion  of  the  division  chiefs  to  where  their 
staff  was  reporting  their  time.  Again, 


thresholds  were  set  and  divisions  were 
given  a  red,  amber,  or  green  rating.  As  a 
result  of  this  focused  attention,  the  pro¬ 
ject  team  discovered  additional  categories 
needed  to  be  added  to  the  system  for 
reporting  project  work.  As  these  short¬ 
comings  and  obstacles  to  adoption  were 
uncovered  by  the  functional  lead  through 
her  analysis  of  the  metrics  and  follow  up 
on  them  with  the  other  division  chiefs,  the 
technical  lead  then  modified  the  cus¬ 
tomization  design  for  the  tool  based  on 
these  lessons  learned.  The  functional  lead 
continued  this  cycle  of  devising  and 
introducing  new  metrics  designed  to 
streamline  the  business  operation  of  the 
system  until  she  had  to  move  onto  her 
next  assignment.  Her  successor  as  project 
leader  continued  the  same  division  of 
responsibilities  and  expanded  her  metrics 
program. 

When  Raytheon  purchased  80  per¬ 
cent  of  Hughes  Aircraft  Company,  a 
large  project  was  created  for  Computer 
Sciences  Corporation  to  separate  the 
Raytheon  portion  of  the  information 
technology  infrastructure  from  the 
Hughes  Aircraft  Company  infrastruc¬ 
ture.  A  senior  project  manager  who 
worked  for  a  program  manager  responsi¬ 
ble  for  a  portfolio  of  projects  saw  a  dra¬ 
matic  demonstration  of  the  power  of  a 
sponsor  when  he  was  asked  by  the  pro¬ 
gram  manager  to  improve  the  disastrous 
results  realized  from  a  pilot  project  for 
desktop  changes.  The  schedule  was  very 
tight  and  the  program  manager  wanted  a 
revised  process  rolled  out  the  following 
week.  The  senior  project  manager  went 
to  the  project  sponsor  that  was  the 
process  owner  and  explained  the  prob¬ 
lem.  They  agreed  additional  staff  (two) 
and  time  (six  weeks)  was  needed  and  the 
sponsor  called  the  program  manager  and 
negotiated  additional  budget  and  sched¬ 
ule  time  to  revise  the  processes  and  do 
another  pilot.  The  revised  process  was  a 
tremendous  success,  and  the  time  spent 
creating  the  process  was  more  than  made 
up  in  the  ensuing  months  of  changes 
contributing  to  a  program  completed 
ahead  of  schedule  and  under  budget 
with  minimal  disruption  to  the  users. 
The  sponsor’s  willingness  to  play  an 
active  role  in  the  project,  along  with  his 
credibility  and  position  was  essential  in 
negotiating  the  additional  staff  and  time 
to  do  the  job  right. 

Conclusion 

In  the  shared  responsibility  of  project  suc¬ 
cess,  the  project  manager  focuses  on  deliv¬ 
erables  and  the  project  sponsor  focuses  on 
outcomes.  Keeping  this  division  of  labor 
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clear,  the  project  sponsor  can  make  the 
project  manager’s  life  immeasurably  easier 
and  greatly  improve  the  odds  for  project 
success.  It  is  a  partnership  worthy  of  the 
project  manager’s  time,  focus,  and  effort. ♦ 
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Shaping  Motivation  and  Emotion  in  Technology  Teams 


Jennifer  Tucker  and  Hile  Rutledge 

Otto  Kroeger  Associates 

In  previous  articles  for  CROSSTALK^  we  described  the  personality  dynamics  of  Information  Technology  teams  and  pre¬ 
sented  a  diagnostic  model for  analysing  the  human  dynamics  of  large  systems  development  programs.  In  this  article,  we  dis¬ 
cuss  the  role  of  motivation  and  emotion  in  maximizing  team  performance  and  present  an  actionable  and  accessible  approach 
for  shaping  both  motivation  and  emotion  —  in  self  in  others,  and  in  teams. 


The  ability  to  motivate  others  is  a  crit¬ 
ical  skill  for  anyone  leading  a  technol¬ 
ogy  team,  and  motivation  lies  at  the  heart 
of  any  action  that  someone  takes.  When 
we  talk  about  influencing  a  technology 
partner,  inspiring  a  team  to  take  a  risk,  or 
managing  people  toward  peak  performance , 
we  are  really  talking  about  motivating 
another  person  towards  some  desired 
end.  Motivating  others  is  an  act  of  lead¬ 
ership. 

Emotions  are  a  natural  byproduct  of 
motivation.  When  we  are  motivated  to  act 
in  a  certain  way  and  those  motives  are  sat¬ 
isfied,  we  feel  good  emotions  such  as 
pride,  belonging,  gratitude,  relaxation,  and 
excitement.  When  we  are  motivated  to  act 
in  a  certain  way  and  those  motives  are  not 
fulfilled,  we  feel  negative  emotions  such  as 
anxiety,  resentment,  guilt,  and  shame. 

Emotions  are  a  natural  part  of  being 
human  and  they  help  define  who  we  are. 
Despite  this,  we  often  see  technologists 
try  to  keep  these  emotions  under  wraps  — 
as  evidenced  by  the  common  phrases  let's 
not  get  emotional  about  this  and  let's  stay  objec¬ 
tive,  people. 

Table  1 :  Reversal  Theory 

Reversal  Theory:  Key  Points _ 

•  General  theory  about  what 
motivates  self  and  others. 

•  Practical  tool  for  understanding 
change  and  your  reaction  to  it. 

•  Provides  a  way  to  recognize 
emotions  and  respond  in  new  ways. 

•  Based  on  30  years  of  research  and 
applied  use. 


We  believe  that  by  better  understand¬ 
ing  and  actively  shaping  motivation  and 
emotion,  we  can  lead  teams  to  greater 
success.  This  article  provides  a  practical 
and  proven  methodology  for  first  recog¬ 
nizing  the  motivational  states  and  result¬ 
ing  emotions  that  both  help  and  hinder 
team  effectiveness  and  then  altering 
those  states  in  order  to  produce  different 
emotions. 

Linking  Motivation  and 
Emotion  to  Performance 

For  many,  motivation  and  emotion  are 
seen  as  somewhat  messy  and  hard  to 
control,  which  can  lead  to  de-emphasiz¬ 
ing  their  importance  in  the  quest  for  a 
more  objective  and  impersonal  approach 
to  technology  problems.  In  the  end, 
when  everything  must  be  converted  to 
the  code  of  a  technology  world,  the 
ambiguity  of  emotions  seems  like  some¬ 
thing  to  avoid. 

Consider,  however,  how  some  of  the 
specific  challenges  we  have  seen  in  our 
work  with  technology  teams  link  to 
motivation  and  emotion: 

•  The  call  to  meet  impossible  deadlines 
amidst  scope  creep  and  oversight 
scrutiny  leads  to  high  levels  of  anxi¬ 
ety  and  turnover  on  a  mission- critical 
software  development  team. 

•  A  team  that  fails  to  adequately  inte¬ 
grate  stakeholders  early  and  frequent¬ 
ly  enough  into  the  system-develop¬ 
ment  process  admits  a  generally  low 
level  of  empathy  for  their  users. 

•  A  program  team  that  has  failed  to 


Figure  1 :  The  Motivational  States  of  Reversal  Theory 


Serious 

Future  Goals,  Achievement 
Values  ambition  and  future  focus 
Avoids  arousal,  risk,  and  anxiety 

1 

Conforming 

Belonging,  Rules 

Values  tradition  and  duty 
Seeks  group  identity 

1 

Mastery 

Power,  Ability 

Values  control  and  strength 
Seeks  competence  and  pride 

1 

Self 

Self-Oriented 

Values  self-reliance  and  own  needs 
Takes  personal  responsibility 

1 

MEANS-ENDS 

Does  motivation  come  from 
achieving  the  goals  or 
experiencing  the  process? 

RULES 

Are  rules,  traditions, 
and  expectations 
supportive  or  restrictive? 

TRANSACTIONS 

Are  motives  based  in 
power  and  control,  or  in  care 
and  emotional  support? 

RELATIONSHIPS 

Are  you  motivated  by 
fulfilling  your  own  needs 
or  another’s? 

1 

Playful 

Process,  Passion,  and  Fun 
Moment  driven  and  present  focused 
Seeks  excitement  to  avoid  boredom 

1 

Rebellious 

Freedom,  Change 

Rules  seen  as  restrictive 
Values  innovation  and  change 

1 

Sympathy 

Relationship,  Care 

Values  compassion 

Seeks  personal  connection 

1 

Other 

Other-Oriented 

Values  giving  and  generosity 
Focused  on  others’  needs 

plan  effectively  for  integration  with 
another  system  in  a  system  of  systems 
effort  professes  strong  feelings  of 
competition  with  the  sister  program. 

•  Developers  on  a  team  feel  so  pres¬ 
sured  to  meet  their  sponsor’s  market¬ 
ing  spin  that  they  fail  to  speak  up 
when  security  requirements  are  com¬ 
promised  in  the  name  of  usability. 

We  have  all  seen  how  personal 
motives  can  impact  a  work  product. 
Recognizing  the  link  between  motivation 
and  performance,  however,  is  only  a  first 
step.  We  need  a  framework  to  help  sys¬ 
tematically  detect  and  then  alter  these 
motives,  leading  to  more  productive  out¬ 
comes. 

Understanding  Motivational 
States 

One  valuable  framework  is  Reversal 
Theory  (Table  1),  a  powerful  set  of  ideas 
that  casts  a  unique  light  on  human  moti¬ 
vation,  emotion,  and  behavior.  Reversal 
Theory  is  a  psychological  theory  address¬ 
ing  the  flexibility  and  changeability  of 
individuals.  The  theory  specifically  focus¬ 
es  on  motivation,  proposing  that  people 
regularly  reverse  between  opposing  psy¬ 
chological  states,  depending  upon  the 
meaning  and  motives  felt  in  different  sit¬ 
uations  at  different  times.  These  reversals 
are  healthy  and  necessary  —  as  situations 
and  meanings  change,  so  do  motives  and 
emotions  [1]. 

Reversal  Theory  proposes  that  key 
emotions  (such  as  anger  and  fear)  and 
values  (such  as  achievement  and  control) 
can  be  traced  to  different  motivational 
states,  which  operate  in  pairs  along  four 
different  focus  areas  called  domains.  We 
spend  our  lives  moving  between  the  dif¬ 
ferent  motivational  states  in  each 
domain,  producing  an  ever-shifting  series 
of  state  combinations.  These  shifts  are 
called  reversals.  We  reverse  between  states 
in  a  domain  based  upon  the  meaning  we 
attach  to  a  situation  and  whether  our  val¬ 
ues  are  being  fulfilled  or  not.  Figure  1 
describes  the  four  domains  and  the  two 
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When  State  Is  Working  Well 

Signs  a  Person  or  Team  May  Need  This  State 

Serious  -  The  Serious  state 
is  focused,  ambitious  and 
time-aware,  driven  to  make 
progress  and  achieve  goals  - 
attaching  significance  to  the 
outcomes  at  stake. 

•  A  lack  of  driving  vision  or  goals;  people  do  not 
see  or  take  seriously  the  risks  that  face  them,  or 
consider  how  today’s  work  impacts  the  future. 

•  Low  follow  through  on  projects  or  commitments, 
wasted  time,  money,  or  other  resources. 

Playful  -  The  Playful  state  is 
enthusiastic,  adventurous, 
and  open  to  risk.  Attaching  no 
significance  to  their  actions  or 
activities,  people  are  free  to 
be  joyous  and  fully  in  the 
moment. 

•  Lack  of  passion  and  enthusiasm,  people  who 
are  anxiety  prone  or  overly  stressed.  Laughter 
and  fun  are  not  frequent  or  consistent  elements 
of  group  or  work  life. 

•  Difficulty  knowing  where  to  start  on  a  project 
because  of  all  the  implications  associated  with 
every  choice. 

Conforming  -  The 

Conforming  state  has  a  clear 
sense  of  duty  and  order  and  a 
unifying  group  identity,  within 
which  both  trust  and  the 
approval  of  others  are  prized. 

•  Mavericks  that  cause  friction  and  needlessly 
reinvent  the  wheel,  rather  than  finding  out  what 
has  worked  in  the  past. 

•  Little  concern  for  tradition  or  people’s 
expectations,  loyalties  and  commitments.  Need 
for  autonomy  has  impaired  teamwork  and  unity. 

Rebellious  -  The  Rebellious 
state  is  innovative  and 
original,  pushing  against 
authority  and  expectations 
and  sparking  change. 

•  Over-commitment  to  routine,  policy,  and 
tradition  or  missing  the  chance  to  innovate  or 
improve.  Thinking  is  limited  to  what  is  known 
and  deemed  appropriate. 

•  Discomfort  with  change  -  tend  to  apply 
incremental  solutions  where  fundamentally 
different  approaches  may  be  needed. 

Mastery  -  The  Mastery  state 
is  motivated  to  be  confident 
and  competent,  focusing  on 
gaining  skills  and  power  to  be 
used  for  an  individual’s  own 
benefit  or  someone  else’s. 

•  People  lack  power,  competence,  problem¬ 
solving  skills,  and  the  ability  to  exercise  control 
over  events,  tasks,  and  action. 

•  Hyper-sensitivity  to  conflict  -  frequent  needs  for 
approval,  affirmation  and  affection. 

Sympathy  -  The  Sympathy 
state  is  interpersonally 
attuned,  sensitive  to  the 
feelings  of  others,  and  both 
gives  and  asks  for  emotional 
support. 

•  Underdeveloped  personal  and  professional 
relationships;  blindness  to  the  benefits  of  trust, 
friendship,  and  human  connection. 

•  The  hunger  for  power  and  drive  to  win  trumps 
personal  relationships,  values,  and  emotional 
considerations. 

Self  -  The  Self  state  is  self- 
aware,  responsible,  and 
individually  accountable. 

•  Avoidance  of  personal  responsibility  or 
accountability. 

•  A  tendency  to  rely  on  others  to  solve  problems 
rather  than  solve  them  alone. 

Other  -  The  Other  state  is 
unselfish  and  motivated  to  be 
part  of  something  that 
transcends  themselves  and 
individual  concerns. 

•  Loners  who  miss  out  on  team  spirit,  community, 
and  connection  to  meaningful  causes. 

•  Strong  focus  on  individual  achievement  or  need 
leads  to  appearance  of  disinterest  in  the  needs 
of  external  interests  or  the  group  overall. 

Table  2:  Recognising  When  New  States  and  demotions  A.re  Needed 


Triggering  the  Serious  State 


opposing  states  in  each  pair. 

The  following  are  some  examples  of 
how  the  states  and  reversals  work  in 
technology  environments: 

•  Mark  is  a  programmer.  More  often 
than  not,  he  is  driven  by  goals,  time 
requirements  and  a  desire  to  achieve 
(Serious  state).  Today,  however,  Mark 
is  fixing  a  bug,  and  in  a  moment  of 
trouble-shooting  he  is  excited  by  the 
intrigue  of  the  problem.  In  the 
process  and  passion  of  the  work, 
time  melts  away  (Playful  state). 

•  Wendy  is  a  test  engineer  who  general¬ 
ly  feels  comforted  and  supported  by 
the  test  routines  that  she  is  supposed 
to  follow  (Conforming  state). 
Suddenly,  however,  she  realizes  the 
standard  approach  misses  a  critical 
element,  and  she  decides  to  stand  up 
and  advocate  for  a  change  (Rebellious 
state). 

•  Bob  is  a  requirements  analyst  who  is 
documenting  the  workflow  of  a  spe¬ 
cific  user  group.  He  begins  the  dis¬ 
cussion  focused  on  developing  his 
expertise  in  the  user’s  business 
process  (Mastery  state).  Later,  when 
users  express  concern  about  having 
to  abandon  their  existing  tools,  he 
instead  begins  to  feel  empathy  for 
their  position  (Sympathy  state). 

•  Karen  is  a  program  manager  who  has 
been  seeking  input  from  others  and 
focusing  on  their  interests  (Other 
state).  Today,  she  stops  and  considers 
what  she  thinks  is  the  right  direction 
for  the  project  on  her  own  (Self 
state). 

Detecting  the  Need  for 
Different  States 

All  the  motivational  states  offer  benefits 
to  both  individuals  and  teams;  these  ben¬ 
efits  can  be  realized  by  developing  access 
to  and  skill  with  all  the  states.  Is  it  the 
right  time  to  advocate  leading  edge  tech¬ 
nology  to  maximize  capability  (Mastery), 
or  is  it  time  to  care  about  the  concerns  of 
other  users  (Sympathy)?  Is  it  time  to  fol¬ 
low  structured  methodologies  (Con¬ 
forming),  or  to  push  against  the  status 
quo  to  innovate  (Rebellious)? 

Recognizing  what  is  working  in  the 
moment  can  be  helped  by  analyzing  pat¬ 
terns  over  time  —  states  underused  in  the 
long  term  may  also  need  to  be  accessed 
more  in  specific  moments.  Table  2  out¬ 
lines  what  a  team  looks  like  when  states 
are  working  well,  and  it  lists  indicators 
that  suggest  the  state  might  be  needed 
more  —  both  in  an  individual  and  in  a 
team  [2]. 


Accessing  Different  States: 
Creating  Reversals 

So  far,  we  have  concentrated  on  recog¬ 
nizing  the  motivational  states  and  associ¬ 
ated  emotions,  as  well  as  described  how 
the  states  play  out.  Now,  we  turn  to 
action  planning.  There  are  a  myriad  of 
actions  available  to  trigger  different  states 
in  an  individual  or  a  team.  Here  are  exam¬ 
ples  that  have  helped  technology  and  sys¬ 
tems  development  teams  we  have  worked 
with. 


The  motive  in  triggering  the  Serious  state 
is  to  increase  the  emphasis  on  goal 
achievement.  One  way  to  do  this  is  to 
introduce  or  enforce  formal  development 
methodologies,  work  breakdown  struc¬ 
tures,  and  risk  management.  (Any  impo¬ 
sition  of  managerial  or  group  expectation 
or  norm  is  also  accessing  the 
Conforming  state;  however,  this  sugges¬ 
tion  focuses  on  goal-orientation,  trigger¬ 
ing  the  Serious  state.)  In  addition,  talk 
about  examples  of  what  failure  might 
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bring:  functional  failures,  reputation  dam¬ 
age,  and  perhaps  even  loss  of  life.  What 
happens  when  your  work  is  not  done  well 
or  on  time?  Talking  about  the  larger  or 
long-term  implications  of  near-term  suc¬ 
cesses  can  create  the  Serious  state  in  a 
team.  What  future  pay-off  might  be  there 
for  work  that  is  done  well  or  on-time? 

Triggering  the  Playful  State 

Triggering  the  Playful  state  is  often  useful 
in  decreasing  anxiety  and  increasing 
emphasis  on  passion  and  fun.  An  effective 
way  of  doing  this  is  to  be  enthusiastic  and 
excited  about  what  you  are  saying  and 
doing  —  raise  your  eyebrows  and  the  pitch 
and  tempo  of  your  voice.  When  a  compli¬ 
cated  problem  emerges,  encourage  others 
to  just  dive  in  anywhere  by  setting  aside  an 
open  period  to  share  cool  ideas.  Many 
teams  suffer  from  an  over-emphasis  on 
the  Serious  state,  so  look  actively  for 
opportunities  to  inject  fun  and  enjoyment 
into  meetings  and  everyday  work  life: 
Supply  and  engage  yourself  with  colored/ 
scented  markers,  bright  paper,  fidget  toys, 
puzzles  and  games,  or  hold  a  party  for  the 
team  or  organization  to  celebrate  some¬ 
thing  or  just  have  fun  together. 

Triggering  the  Conforming  State 

This  state  offers  the  benefits  of  increased 
team  identity,  shared  expectations  of 
process,  and  sense  of  belonging.  One  way 
to  spark  this  state  is  to  introduce  a  capa¬ 
bility  model  to  focus  attention  on  the  way 
things  should  be  done.  This  can  then  be 
carried  through  by  having  regular  meet¬ 
ings  where  team  members  are  all  expected 
to  attend  and  play  a  specific  role  (time¬ 
keeper,  note  taker,  etc.).  Team  identity  can 
also  be  forged  by  engaging  in  ritualistic  or 
ceremonial  group  events  such  as  awards, 
review  sessions,  meetings  and  the  like,  or 
encourage  the  group  to  enter  a  corporate 
contest,  like  an  intramural  baseball  tourna¬ 
ment  or  a  volunteer  event  together.  By 
talking  about  it  before  and  after  the  event, 
you  can  further  encourage  participation 
and  belonging. 

Triggering  the  Rebellious  State 

To  help  increase  feelings  of  freedom  and 
independence,  challenge  someone  or  a 
group  by  suggesting  that  a  given  action  or 
achievement  is  not  possible.  Other  actions 
can  include  provoking  an  argument  or 
healthy  debate;  criticizing  rules,  tradition,  or 
some  opposing  force;  asking  why;  and  prod¬ 
ding  others  to  do  the  same.  The  Rebellious 
state  is  often  triggered  by  questioning,  test¬ 
ing,  and  pushing  against  the  established  way 
of  doing  things  -  urge  your  team  to  seek 
improvements  in  established  approaches. 


Triggering  the  Mastery  State 

In  this  state,  the  motive  is  increasing  con¬ 
fidence,  pride,  and  ability.  One  way  to  do 
this  is  to  take  control  of  a  meeting  or  con¬ 
versation  by  standing  up,  using  both  your 
voice  and  body  to  appropriately  project 
conviction,  confidence,  and  competence 
while  coaching  those  who  work  with  you 
to  do  the  same  when  appropriate.  This 
state  is  also  often  sparked  by  challenging 
and  driving  yourself  or  others  to  craft 
solutions  to  tough  problems  and  find 
answers  to  complex  questions.  Finally,  one 
of  the  best  actions  from  the  Mastery  state 
is  to  teach,  mentor,  or  coach  someone  to 
transfer  power  and  ability  to  another. 

Triggering  the  Sympathy  State 

We  have  encountered  many  teams  that 
would  benefit  from  an  increase  in  empa¬ 
thy  and  care  —  both  for  themselves  and  for 
others.  One  powerful  tool  for  doing  this  is 
to  create  representative  stories  about  differ¬ 
ent  user  groups,  so  that  developers  have  a 
specific  person  in  mind  to  care  about 
when  creating  a  product.  (For  more  on 
this  tool,  see  Cooper’s  reference  to  per¬ 
sonas  in  [3] .)  Within  the  team  itself,  do  not 
resist  telling  people  personally  and  face- 
to-face  how  much  you  value  them.  You 
would  be  amazed  at  the  positive  impacts 
that  come  when  you  treat  your  colleagues 
as  you  would  want  your  best  friend  or 
family  to  be  treated  at  work. 

Triggering  the  Self  State 

Increasing  feelings  of  self-reliance  and 
personal  responsibility  often  requires 
demanding  and  modeling  individual 
accountability  for  decisions  and  actions. 
Be  clear  about  who  owns  what  piece  of  the 
project  or  effort  and  ask  for  updates  on 
individual  progress.  Another  path  is  to 
speak  with  your  team  members  or  col¬ 
leagues  about  their  own  lives  and  profes¬ 
sional  development  plans  and  goals. 
Outside  of  the  team,  what  interests  them? 
(Note:  This  requires  that  the  giver  of  the 
action  be  in  the  Other  state  to  encourage 
the  receiver  to  be  in  the  Self  state.) 

Triggering  the  Other  State 

The  motive  in  the  Other  state  is  to 
increase  feelings  of  altruism  and  transcen¬ 
dentalism.  To  do  this,  speak  to  the  team 
about  the  mission,  the  cause,  the  larger  than 
life  ideas:  calling  out  faith  and  motivation 
and  inviting  others  to  join  the  group  that 
is  fighting  the  good  fight.  (Note:  These 
actions  may  also  spark  the  Conforming 
state  if  framed  as  a  path  to  team  belong¬ 
ing  or  the  Rebellious  state,  if  the  greater 
good  involves  fighting  another  entity,  or  if 
defending  the  rights  of  an  underdog  is 


present.)  Another  way  to  trigger  the  Other 
state  is  to  ask  the  team  to  role  play  or 
brainstorm  what  their  client  or  customer 
is  thinking.  Set  aside  some  time  for  walking 
in  their  shoes  and  determine  how  the  group 
can  meet  those  needs. 

Implementing  Reversal 
Theory  in  Teams 

Now  that  we  have  reviewed  ways  to  detect 
the  states  and  possible  actions  to  trigger 
different  states,  let  us  outline  a  structure 
and  process  for  implementing  this  tool  to 
help  build  and  unify  a  team. 

Step  I:  Gather  Information  -  What’s 
Going  On? 

Before  taking  action,  ask  what  is  going  on 
with  the  team.  Can  you  match  what  you 
see  to  a  motivational  state?  Is  the  team 
generally  overly  stressed  or  rules  bound 
(Serious  or  Conforming)?  Do  they  just 
talk  about  work,  with  little  personal  con¬ 
nection  (Mastery)?  Is,  instead,  the  team 
experiencing  conflict  because  different 
states  are  working  in  opposition?  For 
example,  do  those  who  want  the  team  to 
lighten  up  (Playful)  conflict  with  those  who 
want  the  team  to  tighten  up  (Serious)?  Use 
the  structure  of  the  states  to  analyze  team 
behavior  and  develop  hypotheses  for  what 
is  going  on. 

Step  2:  Identify  Target  -  What  Do 
You  Want  to  See? 

Ask  yourself  next  what  you  are  trying  to 
do.  Does  the  team  need  more  clarity  of 
purpose  (Serious)?  More  creativity 
(Playful,  Rebellious)?  More  group  unity 
and  shared  vision  (Conforming,  Other)? 
Are  you  instead  interested  in  helping  team 
members  recognize  the  value  in  different 
states  to  reframe  an  existing  conflict? 
Review  the  benefits  offered  by  each  state 
described  previously.  Which  state (s)  do 
you  seek  to  create  in  your  team? 

Step  3:  Select  and  Take  Action  - 
What  Changes? 

Many  actions  can  trigger  a  state  that  might 
benefit  the  team.  You  can  also  work  to 
change  the  situation,  so  the  states  experi¬ 
enced  are  more  positive  (e.g.,  for  a  team 
that  is  anxious  in  the  Serious  state,  work  to 
postpone  a  deadline  providing  room  to 
breathe).  In  this  step,  therefore,  select  and 
then  take  an  action  and  see  if  it  creates  the 
change  you  want  to  see.  Three  important 
words  of  caution:  Authenticity  is  key.  If 
your  team  members  perceive  your  actions 
as  manipulative  or  fake,  they  may  feel  dis¬ 
trust  and  cynicism.  As  such,  if  you  want 
your  team  to  be  in  a  certain  state,  try  to 
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trigger  that  state  in  yourself  first.  It  may 
be  easier  for  your  team,  for  example,  to 
access  the  Playful  state  if  they  see  you 
excited  about  the  work  at  hand. 

Step  4:  Monitor  and  Adjust  -  What  Is 
Next? 

Reversal  Theory  focuses  on  change  and 
variability  —  as  such,  one  state  change  can 
cause  others,  both  positive  and  unexpect¬ 
ed.  A  change  in  the  setting  can  then  shift 
states  again;  pushing  one  state  lever  can 
cause  others  to  shift  as  well.  As  such,  the 
final  step  is  to  continue  to  monitor  what’s 
going  on  and  then  repeat  these  four  steps, 
adjusting  actions  to  both  lead  change  and 
respond  to  emerging  emotions  and  needs. 

Conclusion 

Motives  underlie  all  human  action  and  can 
lead  to  a  wide  range  of  emotions  —  both 
positive  and  negative.  In  our  experience, 
effective  leaders  and  teams  do  the  following: 

•  Know  their  own  motivational  tenden¬ 
cies  and  the  impact  they  have  on  others. 

•  Know  the  state  most  needed  by  indi¬ 
viduals,  teams,  and  organizations  at 
any  given  time. 

•  Trigger  specific  states  in  individuals, 
teams,  and  organizations  as  needed. 

•  Model  and  encourage  motivational 
diversity. 

We  frequently  recall  a  deputy  chief 


information  officer  comment  a  few  years 
ago  when  urging  transformational  change 
across  the  Department  of  Defense:  Change 
begins  with  the  people  doing  the  work,  she  said 
[4].  We  agree.  Change  begins  with  each  of 
us:  one  state,  one  choice,  and  one  emo¬ 
tion  at  a  time.^ 
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The  Gauge  That  Pays: 

Project  Navigation  and  Team  Building 


Kasey  Thompson  Tim  Border 

Software  Technology  Support  Center  Self  Management  Systems 

Managers  can  build  better,  more  efficient  teams  and  successfully  navigate  the  toughest  project  environments  in  tandem  by  read¬ 
ing  a  set  of  human  gauges  (indicators)  provided  by  their  project  team.  Reading  these  gauges  requires  observation  of  and  lis¬ 
tening  to,  some  rarely  utilised  aspects  of  teaming.  Once  collected,  the  gauges  act  as  essential  leading  indicators  that  provide 
insight  into  building  stronger  teams  and  arriving  at  a  project  destination  safely  and  on  time. 


Teaming  is  a  fragile  thing  and  no  one 
person  or  organization  has  the  market 
cornered.  Some  do  it  well  on  a  more  con¬ 
sistent  basis,  but  all  have  difficulties.  The 
question  is,  why  is  teaming  so  difficult  and  how 
can  we  regularly  get  better ?  We  might  find 
some  answers  in  the  following  story  of 
how  an  old  navigator  taught  a  lesson  on 
teamwork  as  related  by  the  co-author  of 
this  article,  Tim  Border: 

An  older  gentleman  who  was 
squeezed  into  an  old  Air  Force  uni¬ 
form  stood  next  to  me  while  in  line 
at  the  airport.  I  felt  compelled  to 
thank  him  for  his  service  to  our 
country,  and  he  humbly  apologized 
for  the  way  he  looked  in  his  old 
uniform,  explaining  that  he  had 
been  asked  to  participate  at  a 
World  War  II  convention. 

Coincidentally,  we  were  seated 
next  to  each  other  on  the  plane  and 
picked  up  our  conversation  where 
we  left  off.  He  began  to  tell  me  a 
story  of  when  he  was  a  young  nav¬ 
igator,  and  he  felt  green  along  side 
the  more  seasoned  pilots  on  his 
very  first  mission. 

They  headed  for  their  destina¬ 
tion  with  a  team  of  three  inside  the 
cockpit  and  many  more  supporting 
them  on  the  ground.  Watching  the 
instruments  closely,  he  noticed 
they  were  slightly  off  course.  He 
explained  to  me  that  if  you  are  one 
degree  off  course  and  fly  that  way 
for  one  hour  you  will  be  one  mile 
off  course.  He  kept  waiting  for  the 
pilots  to  make  the  correction. 
Suddenly,  almost  without  warning, 
enemy  aircraft  were  firing  on  their 
plane.  It  happened  so  fast,  he  knew 
they  were  not  going  to  make  it. 

Both  the  pilot  and  co-pilot 
were  killed  in  the  crash. 

“I  didn’t  say  anything  to  them 
about  being  off  course.  I  thought 
they  knew.  They  had  to  know  they 
were  in  enemy  territory.  If  only  I 
could  do  it  again.  I  would  boldly 


state  to  my  ranking  officers  we 
were  off  course.  It  was  my  job  and 
I  didn’t  say  anything.  I  am  still 
haunted  by  the  memory.  As  a  navi¬ 
gator,  I  am  responsible  to  the  team 
to  keep  us  flying  on  course.”  He 
continued,  “Eighty  percent  of  any 
given  flight  is  off  course,  from 
ascending,  moving  through  traffic, 
storms,  and  the  descent.  Flying 
requires  constant  monitoring  and 
adjusting.  Our  instruments  are  crit¬ 
ical  in  helping  us  navigate  course 
challenges,  and  we  consider  them 
to  be  vital  in  providing  accurate, 
timely  information  so  we  have  the 
awareness  to  make  necessary 
changes  if  needed.” 

He  told  me  he  has  spent  a  life¬ 
time  telling  that  story  hoping  indi¬ 
viduals  and  teams  would  learn 
from  his  mistakes  and  listed  the 
following  principles  as  successful 
keys: 

•  Know  where  you  are  going. 

•  Be  aware  of  what  could  take 
you  off  course. 

•  Make  the  necessary  course  cor¬ 
rections  as  soon  as  possible 
when  off  course. 

•  Execute  with  integrity  and 
communicate  continually. 

We  now  apply  and  share  his  wisdom  in 
regard  to  building,  maintaining,  and  most 
importantly,  guiding  successful  teams. 

Hard  and  Soft  Gauges: 
Traditional  Versus  Human 
Indicators 

Much  like  the  navigator  needed  instru¬ 
mentation,  we  need  to  choose  the  correct 
gauges  to  keep  our  team  on  the  road  to 
success.  Some  common  and  useful  hard 
gauges  are  cost,  quality,  and  schedule.  These 
are  valuable  for  showing  managers  they 
are  off  track  and  are  easily  measurable. 
However  the  information  indicates  very 
little  about  what  actually  happened  in  the 
process.  The  information  provided  by 


these  gauges  is  not  enough  to  ascertain 
where  things  went  wrong  and,  more 
importantly,  why  things  went  wrong. 
These  hard  gauges,  while  useful,  leave 
managers  wanting  for  additional  informa¬ 
tion  to  make  decisions  on  how  to  effi¬ 
ciently  correct  what  has  gone  wrong.  This 
wanting  hints  at  the  need  for  additional 
gauges  that  provide  more  leading  indica¬ 
tors  of  early  warnings  and  paint  a  more 
complete  picture  of  reality  when  com¬ 
bined  with  the  hard  gauges. 

It  would  be  nice  to  have  a  single  warn¬ 
ing  light  that  burned  red  at  the  moment 
projects  go  astray.  Unfortunately,  that 
gauge  does  not  exist,  but  we  may  have 
gauges  that  can  produce  the  same  warning 
if  astutely  measured  and  monitored. 

So  what  is  the  gauge  that  pays?  It  is  the 
human  gauge  or  soft  gauge  —  otherwise 
known  as  the  individual  members  of  our 
project  teams.  It  becomes  essential  in 
times  of  project  peril  to  speak  with  the 
people  performing  the  work.  Team  mem¬ 
bers  act  as  the  soft  gauges,  or  early  warn¬ 
ing  systems.  Some  useful  soft  gauges  are 
relational  conflict ,  communications,  and  function¬ 
al  conflict  (see  Figure  1).  Managers,  with  the 
use  of  soft  gauges,  can  pinpoint  a  desired 
destination  and  correct  the  team’s  course 
when  combined  and  contrasted  with  hard 
gauge  readouts.  Soft  gauges  provide  added 
information  to  arriving  safely  and  on  time, 
all  while  building  a  highly  dynamic  team 
en  route  to  success. 

This  article  includes  soft  gauge  infor¬ 
mation  regarding  reading  the  gauge,  making 
course  corrections ,  and  performing  observational 
insights  (OI).  The  OI  section  reflects 
observations  of  a  team  formed  four  years 
ago  as  it  struggled,  grew,  and  overcame 
obstacles  through  the  use  of  soft  gauges. 

Relational  Conflict  Gauge: 

How  Far  Off  Track  Are  We? 

Teams  will  always  have  an  intrinsic  flaw 
that  can  potentially  derail  progress.  That 
flaw  resides  in  the  fact  that  they  are  com¬ 
posed  of  members  of  the  human  race. 
One  significant  difficulty  we  humans  have 
is  the  sometimes  conflictive  ways  in  which 
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we  interact,  communicate,  and  function  in 
an  interdependent  environment.  The 
resultant  conflict  contained  in  team  inter¬ 
action  is  a  powerfully  destructive  force, 
but  it  is  also  a  source  of  unification  when 
used  correctly 

There  is  an  old  riddle  that  asks,  what  can 
blind  a  man  jet  make  him  see?  What  erodes 
mountains  jet  constructs  buildings?  The  answer 
is  sand,  as  it  is  a  fundamental  element  in 
the  making  of  glass  (spectacles/eyeglass¬ 
es)  and  brick  (the  building  blocks  of  many 
an  edifice).  Sand  also  blinds  those  poor 
souls  who  are  trapped  in  a  desert  storm, 
and  wears  down  mountains  and  structures 
through  erosion.  The  answer  could  very 
well  have  been  conflict  as  it  possesses  the 
same  qualities  as  sand.  One  component  of 
conflict  can  destroy  relationships,  bonds, 
and  synergy  when  attempting  to  build 
teams.  But,  when  used  correctly,  there  is 
an  underutilized  component  of  conflict 
that  unites,  clarifies,  focuses,  and  moves 
teams  forward.  Think  of  conflict  as  a  tool. 
This  tool,  like  most  others,  can  be  used  for 
destruction  or  construction.  Stephen  P. 
Robbins  [1]  describes  the  destructive  com¬ 
ponents  of  conflict  as  relational  and  the 
constructive  component  as  functional. 
Monitoring  and  utilizing  these  two  types 
of  conflict  are  essential  in  building  an 
effective  team. 

Relatively  little  time  is  needed  to 
understand  the  use  of  relational  conflict 
as  a  gauge.  Relational  conflict  resides  in 
emotional  differences  that  have  little  to 
do  with  process,  purpose,  or  function. 
These  emotions  trigger  the  fight  or  flight 
response  in  the  brain,  draining  blood 
away  from  the  higher  functioning  por¬ 
tion  called  the  neocortex.  Reasoning  and 
decision  making  are  then  sent  to  the 
brain  stem,  sometimes  referred  to  as  the 
reptilian  brain ,  where  reasoning  capabili¬ 
ties  are  significantly  reduced.  Such  emo¬ 
tional  differences  might  include  conflict 
over  personal  styles,  choices,  and  work 
habits.  Relational  conflict  often  may  stem 
from  issues  unrelated  to  work  or  even 
social  or  political  issues,  stall  the  project 
team’s  creative  engines  as  blaming  begins 
and  sides  of  issues  are  chosen,  and  cause 
the  team  to  fracture,  decompose,  and 
reduce  overall  proficiencies.  This  decom¬ 
position  is  usually  the  result  of  either 
perceived  or  actual  lack  of  respect  for 
fellow  teammates.  As  quoted  in  [2], 
“Respect  is  like  air.  We  don’t  think  about 
it  until  it’s  gone  —  once  it’s  gone,  it’s  all  we 
think  about.” 

Like  an  engine  temperature  gauge, 
relational  conflict  requires  constant  mon¬ 
itoring  as  team  differences  inevitably 
arise.  Observation  and  awareness  are  the 


Relational  Conflict  Gauge  —  Negative  Comments 


Communication  Gauge — Ambiguity 


first  steps  in  any  course  correction,  and 
managers  need  only  to  begin  to  take  and 
make  note  of  team  behavior.  Conflict  is 
not  always  easy  to  spot.  In  most  cases, 
conflict  begins  with  subtleties  that  com¬ 
monly  go  unnoticed.  Such  subtleties  grow 
into  larger  conflicts,  and  by  that  time,  the 
damage  has  been  done  and  team  chem¬ 
istry  has  broken  down.  It  is  suggested  that 
managers  make  unobtrusive  fly-on-the-wall 
type  observations  so  as  not  to  intrude  on 
the  work  performed  or  create  artificial 
behaviors  from  the  team  and  then  witness 
authentic  team  dynamics  and  behaviors. 

The  concept  of  conflict  appears  rudi¬ 
mentary  on  the  surface,  but  the  real 
understanding  of  conflict  occurs  in  rec¬ 
ognizing  the  ramifications  stemming  from 
conflicting  groups  and  individuals.  The 
actual  extent  and  cost  of  conflict  is  diffi¬ 
cult  to  assess,  but  managers  can  pinpoint 
the  source  of  conflict  through  monitor¬ 
ing  team  interactions  and  note  the  point 
at  which  teams  become  derailed  when 
observed  with  a  watchful  eye.  Allowing, 
or  merely  coping  with,  conflict  is  too 
damaging  and  expensive  to  permit. 
Simply  addressing  the  conflict  without 
understanding  the  very  nature  of  the  issue 
is  dangerous  and  can  compound  prob- 


Relational  Conflict  Gauge  —  Team  Decomposition 


Functional  Conflict  Gauge  —  Teaming 


lems.  Observations  noting  significant 
breakdowns  in  communication  need  to  be 
taken  during  team  meetings  or  other  team 
interactions  on  weekly  intervals. 
Managers  can  look  at  the  interaction 
amongst  the  team  to  decipher  if  relation¬ 
al  conflict  is  present  and  to  what  degree  it 
has  affected  the  team.  Relational  conflict 
typically  causes  team  decomposition  in 
the  following  three  stages: 

•  The  first  stage  is  communicative  detach¬ 
ment,  where  people  become  unwilling 
to  constructively  communicate  with 
one  another  due  to  the  belief  that  a 
person  is  doing  things  incorrectly  or 
that  they  have  been  personally 
wronged.  Individuals  now  need  to 
prove  themselves  right  by  taking  a  hard 
stand  against  the  other(s)  in  defense  of 
their  point-of-view.  Managers  may 
notice  a  reduction  in  lines  of  commu¬ 
nication  or  posturing  and  position-tak¬ 
ing  as  overall  willingness  to  work 
together  dissipates.  Negotiations  and 
solution- finding  are  stymied  until  the 
positional  impasse  is  resolved. 

•  The  second  stage  is  selective  detachment. 
Here,  alliances  are  formed  based  on 
the  individual  team  member’s  views  of 
who  is  right  and  wrong  in  respect  to 


November  2007 


www.stsc.hill.af.mil  I  5 


Working  as  a  Team 


the  disagreement.  Selective  micro-teams 
are  formed  within  the  greater  team  at 
large.  Micro-teams  then  informally 
prepare  strategies  for  their  success  at 
the  exclusion  of  the  other  remaining 
team  members. 

•  The  third  and  final  stage  factionism 
refers  to  the  state  of  functionality  of  a 
decomposing  team.  During  faction¬ 
ism,  multiple  teams  function  where  a 
singular  team  once  existed.  Effort  is 
duplicated  and  confusion  insidiously 
increases.  The  collective  intellectual 
power  is  hampered  and  team  profi¬ 
ciency  levels  drop.  Micro-teams  begin 
to  establish  new,  ad-hoc  processes  as 
to  how  to  perform  work  in  a  new  and 
dysfunctional  environment.  Individual 
cultures  are  formed.  Incidentally,  fac¬ 
tionism  cultures  breed  future  factions 
until  one  team  possibly  becomes  many 
warring  individuals  battling  in  person¬ 
al  isolation. 

It  is  helpful  to  understand  this  system¬ 
atic  decomposition  of  typical,  dysfunc¬ 
tional  teams  to  better  understand  the 
depth  of  the  dysfunction,  and  to  further 
recognize  how  to  avoid  or  diffuse  rela¬ 
tional  conflict  in  our  own  teams. 

Reading  the  Relational  Conflict 
Gauge 

1.  Record  and  retain  the  frequency  of 
negative  personal  or  team  comments 
made  in  team  meetings. 

*  Note:  An  increase  in  negative  com¬ 
ments  is  a  lead  indicator  of 
impending  team  decomposition. 

2.  Chart  what  members  are  on  which  side 
of  the  issue  but  do  not  take  a  position. 
Categorize  the  depth  of  decomposi¬ 
tion  in  terms  of  communicative 
detachment,  selective  detachment,  or 
factionism  via  the  previous  definitions. 
Take  note  of  the  issue  that  is  driving 
the  disagreement  so  it  can  be  re¬ 
addressed  later  during  the  functional 
conflict  stage. 

Making  Course  Corrections 

Begin  to  listen  and  gather  (document) 
points-of-view  from  both  sides.  Make 
every  attempt  to  understand  each  side  of 
the  story  without  agreeing  with  or  aligning 
yourself  with  one  side  or  the  other. 

Observational  Insights 

The  observed  team  cycled  through  each  of 
the  three  stages  of  team  decomposition 
three  times  in  their  four  years  together. 
Each  cycle  began  with  a  singular  act  of 
communicative  detachment  between  two 
members. 


Communication  Gauge: 
Communication  Saturation 
and  Understanding 

The  communication  gauge  is  read  by 
individually  asking  team  members  about 
the  purpose  of  what  they  do,  why  this 
project  exists,  and  what  success  looks 
like  for  the  purpose  of  team  under¬ 
standing.  Projects  are  guaranteed  to  be 
off-track  if  any  number  of  team  mem¬ 
bers  cannot  answer  these  questions  in  a 
consistent  manner.  Frequently,  the  goal 
of  a  project  is  misunderstood.  A  survey 
of  more  than  700  employees  and  first- 
line  managers  from  various  fields  taken 
during  the  last  four  years  reveals  that 
only  one  of  six  employees  feel  they 
received  adequate  initial  communica¬ 
tions  regarding  the  purpose  and  direc¬ 
tion  of  the  project  on  which  they 
worked  [3].  The  survey  also  indicates 
that  only  one  in  nine  employees 
received  ongoing  clarification  regarding 
project  purpose  and  direction.  The  sur¬ 
vey  reveals  an  ongoing  need  for  man¬ 
agers  to  discover  what  points  of  a  pro¬ 
ject  are  misconstrued  and  then  clarify  in 
order  for  the  team  to  better  understand 
the  overall  purpose  of  the  project  exe¬ 
cution.  The  goal  of  this  gauge  is  to 
reach  a  level  called  communication  satura¬ 
tion ,  meaning,  every  person  on  the  team 
possesses  all  the  information  and  under¬ 
standing  needed  to  do  their  job  effec¬ 
tively  and  in  concert  with  other  team 
members.  Communication  saturation 
among  team  members  includes  knowing 
the  purpose  or  goal  of  a  project,  the 
interconnectivity  of  their  individual 
tasks  with  those  both  upstream  and 
downstream,  a  vivid  description  of  a 
successful  project  outcome,  and  how 
progress  will  be  measured.  Such  com¬ 
munication  facilitates  team  empower¬ 
ment  and  assists  managers  in  providing 
guidance  that  is  most  needed. 

Franklin  Covey  Organizational 
Solutions  reports  that,  on  average,  only 
15  percent  of  employees  can  correctly 
list  their  companies’  top  three  goals,  and 
only  12  percent  can  ascertain  how  well 
they  are  doing  in  regard  to  those  goals 

[4]- 

Dr.  Randall  W.  Jensen,  noted  cost 
estimator,  stated  the  following: 

Software  development  is  the 
most  communication  intensive  of 
all  engineering  processes.  This 
unique  software  process  charac¬ 
teristic  suggests  significant  pro¬ 
ductivity  gains  are  more  likely  to 
be  realized  through  communica¬ 


tion  improvement,  rather  than 
through  technology.  Communi¬ 
cation  effectiveness  is  a  people 
issue  controlled  by  organization 
structure,  management  approach, 
and  the  development  environ¬ 
ment.  [5] 

Communication  among  team  mem¬ 
bers  becomes  increasingly  critical  on 
software  teams  due  to  the  interconnec¬ 
tivity  of  software,  hardware,  systems, 
networks,  and  most  importantly,  the 
people  attempting  to  manage  the  rela¬ 
tionship  of  them  all. 

Reading  the  Communication 
Gauge 

1.  On  a  regular  but  not  too  frequent 
basis  (quarterly  is  suggested),  gather 
input  from  the  team  on  the  follow¬ 
ing  questions: 

a.  What  is  the  goal  or  the  purpose 
of  the  project? 

b.  How  does  your  job  relate  to  oth¬ 
ers  in  the  process? 

c.  What  does  a  successful  project 
look  like? 

d.  How  are  we  measuring  progress? 

e.  What  would  you  do  differently  to 
improve  the  process? 

*  Note:  These  questions  are  also 
useful  as  part  of  an  annual  per¬ 
formance  review  to  clarify  and 
align  goals  and  measurements. 
Maintaining  safety  during  reviews 
is  best  achieved  when  the  manag¬ 
er  approaches  team  members  in 
an  authentic  spirit  of  helping  and 
for  the  purpose  of  better  under¬ 
standing  by  all  parties. 

2.  Concurrently  ask  team  members  to 
describe  how  they  directly  add  to  the 
success  of  the  project  and  how  they 
are  measuring  success. 

*  Note:  Successful  projects  require 
all  members  of  a  team  to  be 
vividly  clear  regarding  the 
answers  to  the  above  questions. 
One  or  two  unclear  or  unfocused 
team  members  are  lead  indicators 
of  future  confusion.  Remember: 
confusion  breeds  confusion. 

Making  Course  Corrections 

1.  Listen  for  ambiguity  and  misdirec¬ 
tion  in  the  individual’s  response, 
then  clarify  and  redirect  energies.  Be 
open  and  allow  input  on  how  indi¬ 
viduals  will  add  to  and  measure 
future  success. 

2.  Communicate  the  larger  vision  and 
specify  detailed  instructions  where 
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needed.  This  is  an  opportunity  for 
managers  to  clearly  convey  their 
goals  and  specific  needs  in  relation 
to  larger  organizational  goals  while 
gathering  fresh  ideas  from  the  team. 

3.  Retain  individual  ideas  from  the 
team  for  future  proposals  during  the 
functional  conflict  phase,  as  it  will 
require  newly  proposed  ideas  for 
constructive  discussions. 

4.  Together  with  the  team  member, 
redefine  the  description  of  the  team 
member’s  role  in  alignment  with  the 
project  goal,  and  document  in  it  the 
team  charter. 

Observational  Insights 

The  observed  team  regularly  held  meet¬ 
ings  where  input  from  individuals  was 
gathered  and  used  in  team  strategies. 
Redundancies  were  removed  and 
responsibilities  were  better  understood 
by  the  entire  team  which  led  to  better 
overall  team  efficiency.  There  still 
remains  some  ambiguity  regarding  indi¬ 
vidual  roles,  but  confusion  regarding 
who  does  what  and  why  was  significant¬ 
ly  reduced. 

The  team  also  held  a  meeting  to  cre¬ 
ate  a  team  charter  where  the  previous 
questions  were  addressed.  Each  mem¬ 
ber  defined  their  own  role,  provided 
input  to  team  goals  and  purposes,  and 
then  cross-checked  the  document  with 
management  to  assure  alignment.  The 
team  charter  has  since  been  used  many 
times  to  provide  team  guidance  regard¬ 
ing  process  and  procedures. 

Functional  Conflict  Gauge: 
Course  Correction  (Getting 
Back  On  Track) 

The  useful  portion  of  conflict  is  func¬ 
tional  conflict,  and  it  is  an  effective 
means  of  getting  teams  going  in  the 
right  direction  again.  Functional  conflict 
is  a  disagreement  regarding  how  to  do 
the  job,  the  goal  of  the  project,  which 
processes  to  use,  or  which  methodology 
to  employ,  and  it  is  devoid  of  emotion. 
Decomposing  teams  can  use  focused 
functional  discussions  to  regain  unity. 
Factionism  stage  teams  are  in  need  of  a 
compelling  and  bonding  force  to  mar¬ 
shal  its  efforts  and  move  in  a  common 
direction.  Functional  conflict  provides 
that  force  by  offering  some  common 
ground.  That  common  ground  is  found 
in  generally  held  beliefs  such  as  the 
importance  of  quality  or  customer  satis¬ 
faction.  Team  discussions  need  to  begin 
somewhere  and  high-level  topics  such 
as  quality  or  customer  satisfaction  are 


normally  safe  launching  areas  to  more 
in  depth  discussions.  Managers  can 
drill-down  to  more  polarizing  and 
specifics  issues  once  safety  to  discuss 
these  subjects  without  blaming  is 
restored. 

Safety  is  fragile  and  is  best  achieved 
by  speaking  in  terms  of  facts  as 
opposed  to  sharing  opinions  or  stories. 
Crucial  Conversations  [2]  suggests 
restoring  safety  by  following  the 
STATE  methodology: 

•  Share  your  facts.  Begin  by  speaking 
solely  in  terms  of  facts  to  build  a 
foundation. 

•  Tell  your  story.  Explain  how  you  see 
what  has  happened  in  the  past. 

•  Ask  for  others’  opinions.  Ask  others 
how  they  see  the  situation. 

•  Talk  tentatively.  Do  not  overstate 
things  or  draw  conclusions. 

•  Encourage  Testing.  Ask  others  to 
find  flaws  in  your  story. 

“Managers  can 
drill-down  to  more 
polarizing  and  specific 
issues  once  safety  to 
discuss  these  subjects 
without  blaming  is 
restored.” 

The  STATE  methodology  is  easy  to 
apply  and  constructive  when  used  as 
rules  for  team  discussions.  Each  mem¬ 
ber  of  the  team  is  given  the  opportuni¬ 
ty  to  share  their  viewpoint  on  the  issues 
at  hand.  Using  STATE  produces  safety 
that  in  turn  produces  more  accurate, 
untainted  reporting.  It  is  here  where 
managers  gather  essential  cause  and 
effect  data  that  truly  indicates  where 
problems  with  budget,  schedule,  and 
quality  originated.  STATE  limits  the 
emotional  flare-ups  caused  by  relational 
conflict  and  refocuses  discussions  to 
functional  topics.  Functional  conflict 
unites  teams  by  focusing  their  attention 
and  energies  back  on  solving  problems 
and  accomplishing  tasks  rather  than  jus¬ 
tifying  positions  in  a  conflict. 
Participants  in  functional  conflict 
require  their  brains  to  use  cognitive  rea¬ 
soning  skills  to  discuss  facts  and  solu¬ 
tions  via  the  neocortex  as  well  as  other 
higher  capacities  of  the  larger  cerebral 
cortex.  Blood  flow  returns  to  this  indis¬ 


pensable  grey  matter  as  individuals 
begin  complex  problem  solving  or  ratio¬ 
nally  addressing  possible  strategies  for 
achieving  goals  without  derailing  emo¬ 
tions  present.  The  human  brain  is  less 
likely  to  focus  on  relational  conflict 
issues  because  it  is  limited  to  cognitive¬ 
ly  focusing  on  a  singular  issue. 
Functionally  thinking  individuals  are 
now  more  apt  to  reason  with  each  other 
and  combine  to  find  the  best  answer  for 
the  purpose  of  team  success  or  solving 
a  difficult  problem  as  opposed  to  prov¬ 
ing  one  side  right  or  wrong.  The  envi¬ 
ronment  becomes  one  of  safety  where 
people  can  disagree  with  each  other 
respectfully  without  fear  of  offense. 
This  process  reunites  teams  as  they 
explore  potential  solutions  together. 
Managers  monitor  this  gauge  by  embed¬ 
ding  themselves  in  team  discussions, 
observing  discussion  topics,  and  noting 
the  nature  of  the  discussions.  This  is  the 
time  to  share  the  team’s  ideas  collected 
from  discussions  held  during  the  read¬ 
ing  of  the  communication  gauge  (com¬ 
munication  gauge  —  making  course  cor¬ 
rections  No.  3).  Managers  assist  team 
members  to  stay  on  task  by  refocusing 
discussions  on  function,  not  personal 
stories  or  opinions. 

Robbins  states  the  following: 

Conflict  is  constructive  when  it 
improves  the  quality  of  deci¬ 
sions,  stimulates  creativity  and 
innovation,  encourages  interest 
and  curiosity  among  group  mem¬ 
bers,  provides  the  medium 
through  which  problems  can  be 
aired  and  tensions  released.  [i] 

Re-stated,  functional  conflict  is  the 
method  for  engagement  in  creative 
problem  solving  and  inquisitiveness. 
Robbins’  studies  indicate  that,  at  the 
end  of  this  process,  a  team  will  be  more 
cohesive  and  have  more  robust  process¬ 
es,  products,  and  services. 

Reading  the  Functional  Conflict 
Gauge 

1.  During  team  interactions,  chart  the 
frequency  of  functional  comments 
such  as  commentary  regarding 
process,  procedures,  measurements, 
objectives,  goals,  and  proposed  solu¬ 
tions  to  problems. 

*  Note:  An  increase  of  functional 
comments  indicates  an  increase 
in  team  health,  ingenuity,  clarity, 
creativity,  and  focus. 

2.  Review  the  charts  made  during  the 
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relational  conflict  stage  (reading  the 
relational  conflict  gauge  #2)  to  dis¬ 
tinguish  if  micro-teams  are  dissolv¬ 
ing  back  into  the  team  at  large.  Be 
aware  that  more  effort  and  more 
focus  on  functional  matters  will  be 
required  to  reunite  teams  depending 
upon  the  depth  of  decomposition, 

i.e.,  communicative  detachment, 
selective  detachment,  or  factionism. 

Making  Course  Corrections 

1.  Set  team  meeting  ground  rules  to 
use  the  STATE  methodology. 

2.  Actively  redirect  and  refocus  team 
members  on  functional  matters  only. 

3.  Begin  team  functional  discussions 
using  safe,  high-level  topics. 

4.  Move  into  fore  volatile  issues  only 
after  safety  is  restored. 

5.  Empower  the  team  by  infusing  col¬ 
lected  team  ideas  (communication 
gauge  —  making  course  corrections 
#3)  after  reunification  has  begun. 

6.  Implement  team  decisions  and 
watch  them  go. 

Observational  Insights 

The  observed  team  hit  their  low  point 
in  year  three.  A  specific  and  successful 
functional  conflict  meeting  was  held  in 
an  effort  to  build  back  up  from  the  fac¬ 
tionism  stage.  The  meeting  was  gov¬ 
erned  by  ground  rules  where  no  opin¬ 
ions/stories  could  be  told.  All  dialogue 
was  pointed  toward  solutions  and  facts. 
As  a  result,  the  team  recovered  and 
began  to  strengthen  both  socially  and 
functionally.  Later,  the  team  discovered 
and  implemented  STATE  methodolo¬ 
gies  as  part  of  their  culture. 

Since  that  meeting,  the  team  has  suf¬ 
fered  three  additional  occurrences  of 
communicative  detachment  and  has  yet 
to  decompose  into  selective  detach¬ 
ment. 

Currently  the  team  is  beginning  to 
demonstrate  characteristics  of  a  highly 
dynamic  team  such  as  increased  com¬ 
munications,  sociability,  forthrightness, 
utilization  of  individual’s  diverse 
strengths,  and  a  willingness  to  support 
other  members. 

Conclusion  -  Putting  It  All 
Together 

The  information  needed  to  apply  the 
four  principles  of  a  successful  mission 
offered  by  the  navigator  (know  where 
you  are,  be  aware  of  what  could  take 
you  off  course,  make  necessary  correc¬ 
tions,  execute  with  integrity  and  com¬ 
municate  continually)  are  sometimes 


hidden  in  our  traditional  hard  gauges, 
but  it  is  more  apparent  and  readily  avail¬ 
able  in  our  soft  gauges.  We  only  need  to 
be  willing  to  observe  and  listen. 
Longevity  and  good  team  health  will 
result  from  a  disciplined  and  measurable 
approach  to  the  following: 

•  Observed  relational  conflict. 

•  Increased  communications. 

•  Focused  functional  discussions. 

Teams  will  always  flounder  and  fail 

to  some  degree,  but  learning  the  cause 
and  making  the  correction  at  an  early 
juncture  will  save  time  and  money.  Soft 
gauges  provide  the  earliest  warning  sys¬ 
tem  when  monitored  correctly,  iterative¬ 
ly,  and  diligently.  Soft  gauges  provide 
information  for  managers  to  know  how 
to  successfully  navigate  project  paths 
and  allow  their  teams  to  arrive  at  their 
destinations  on  time  and  intact.  Team 
members,  like  the  navigator,  are  invalu¬ 
able  and  possess  a  need  to  feel  safe  in 
providing  what  they  view  as  pertinent 
information  to  those  who  can  act  upon 
it.  The  navigator  learned  the  lesson  that 
team  success  is  reliant  upon  one  anoth¬ 
er  the  hard  way.  Tom  Demarco  states, 
“An  individual  can  only  succeed  to  the 
extent  that  the  whole  prospers.  And  the 
whole  can  only  prosper  to  the  extent 


that  everyone  does  well”  [6].  Managers 
cannot  be  successful  unless  their  team  is 
successful  and  monitoring  these  soft 
gauges  will  confirm  that  the  human 
gauge  is  the  one  that  pays.^ 
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Why  Should  I  Use  the  People  CMM? 


Margaret  Kulpa 

AgileDigm,  Incorporated 

Has  jour  organisation  started  a  process  improvement  effort  onlj  to  have  it  stall \  or  even  worse ,  fail ?  Are  you  having  trouble 
attracting  and  keeping  the  right  employees?  Are  you  seeing  organisational  skills  walk  out  your  door ?  Perhaps  you  have  just 
finished  a  successful  Capability  Maturity  ModeP  (CMM®)  Integration  (CMMI®)  effort  and  are  wondering ,  What’s  next? 

Then  maybe  you  should  try  using  the  People  CMM. 


In  the  old  Introduction  to  the  CMM 
class,  there  is  an  interesting  graphic 
(Figure  1).  The  figure  consists  of  a 
three-legged  stool.  The  seat  represents 
the  organization.  One  leg  represents 
Technology,  one  leg  represents  Process, 
and  one  leg  represents  People.  What  the 
graphic  shows  is  that,  in  order  to  have  a 
stable  organization,  all  three  legs  must  be 
present.  Without  one  or  more  of  them, 
the  stool  topples  over.  The  CMM  for 
Software,  and  now  the  CMMI  series, 
address  the  process  concerns.  Various 
methodologies  (for  example,  Agile 
development,  Microsoft  certification, 
object-oriented  design  and  development) 
address  technology.  But  the  one  area 
often  left  unaddressed  by  organizations 
is  people. 

What  Is  the  People  CMM? 

The  People  CMM  was  written  to  address 
the  need  to  integrate  effective  people 
practices  with  process  and  technology.  It 
is  a  staged  maturity  model  that  begins 
with  a  basic  set  of  practices  and 
advances  through  ensuing  stages  of 
sophistication  and  maturity  (Table  1)  [1]. 
The  People  CMM  has  been  around  in  an 
earlier  version  since  1995  and  was  updat¬ 
ed  in  2002  based  on  best  practices  gath¬ 
ered  from  practical  application  in  organi¬ 
zations.  Although  the  model  was  origi¬ 
nally  written  for  the  problems  facing  the 
software  industry,  the  focus  has  now 
been  expanded  to  any  organization  that 
depends  on  people  to  accomplish  work 
—  and  that  should  be  just  about  every¬ 
body. 

There  are  five  maturity  levels,  with 
each  maturity  level  laying  the  foundation 
for  the  next  maturity  level.  As  each  level 
(or  stage)  is  achieved,  the  capability  of 
the  organization  to  do  work,  both  now 
and  in  the  future,  increases.  Each  matu¬ 
rity  level  contains  anywhere  from  three 

®  Capability  Maturity  Model,  CMM,  and  CMMI  are  regis¬ 
tered  in  the  U.S.  Patent  and  Trademark  Office  by  Carnegie 
Mellon  University. 


to  seven  process  areas  (PAs).  The  PAs 
are  a  collection  of  best  practices  gath¬ 
ered  from  highly  functioning  organiza¬ 
tions,  grouped  by  a  common  theme  into 
process  categories. 

•  At  Maturity  Level  1 ,  there  are  no  PAs. 
Maturity  Level  1  is  characterized  by 
chaos  and  inconsistency.  Work  is 
being  accomplished,  but  no  one  is 
really  sure  how.  Status,  performance, 
and  quality  are  unpredictable. 

•  Maturity  Level  2  is  the  managed  level. 
At  this  level,  a  disciplined  approach 
(via  following  the  sequence  of  best 
practices  in  the  Level  2  PAs)  is  intro¬ 
duced  into  basic  workforce  practices 
to  promote  repeatable  outcomes. 
However,  each  project,  unit,  or  work¬ 
group  has  its  own  way  of  performing 
tasks. 

•  Maturity  Level  3  is  the  defined  level. 
This  level  is  characterized  by  having 
an  organizational  way  of  conducting 
business.  Best  practices  from  units 
and  workgroups  established  at 
Maturity  Level  2  bubble  up  to  the 
organizational  level,  resulting  in 
effective  organizational  policies  and 
procedures.  Managers  and  workers 
can  tailor  this  organizational  way  of 
doing  things  as  necessary,  but  the 


Figure  1 :  Quality  Teverage  Points 


original  organizational  process  pro¬ 
vides  some  structure  and  sanity  to 
the  way  work  is  done. 

•  Maturity  Levels  4  and  5  provide  more 
autonomy  to  the  workforce  and  pro¬ 
vide  management  by  the  numbers. 
Quantitative  data  are  used  to  align 
workforce  practices  with  current  and 
future  business  needs,  and  to  chart  a 
path  of  improvement  that  is  measur¬ 
able  and  highly  predictable. 

There  are  also  PA  threads  document¬ 
ed  in  the  model  (see  Table  2,  next  page) 
[2].  These  threads  show  how  the  PAs  are 
integrated  and  increase  in  sophistication 
as  the  maturity  level  increases.  The  PA 
threads  are  the  following: 

•  Developing  competency.  Develop 
individual  capabilities  to  perform 
immediate  and  future  work  in  order 
to  contribute  to  organizational  per- 


Table  1 :  Stages  of  People  CMM 


Level 

Process  Areas 

5 

Optimizing 

•Continuous  Workforce 
Innovation 
•Organizational 

Performance  Alignment 
•Continuous  Capability 
Improvement 

4 

Predictable 

•Mentoring 

•Organizational  Capability 
Management 

•Guantitative  Performance 
Management 
•Empowered  Workgroups 
•Competency-Based  Assets 
•Competency  Integration 

3 

Defined 

•Participatory  Culture 
•Workgroup  Development 
•  Competency-Based 

Practices 

•Career  Development 
•Competency  Development 
•Workforce  Planning 
•Competency  Analysis 

2 

Managed 

•Compensation 
•Training  and  Development 
•Performance  Management 
•Work  Environment 
•Communication  and 
Coordination 
•Staffing 
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Levels 

People  CMM  Threads 

Developing 

Competency 

Building 
Workgroups 
and  Culture 

Motivating  and 

Managing 

Performance 

Shaping  the 
Workforce 

5 

Optimizing 

•  Continuous  Capability  Improvement 

•  Organizational 
Performance 
Alignment 

•  Continuous 
Workforce 
Innovation 

4 

Predictable 

•  Mentoring 

•  Competency 
Based  Assets 

•  Competency 
Integration 

•  Empowered 
Workgroups 

•  Quantitative 
Performance 
Management 

•  Organizational 
Capability 
Management 

3 

Defined 

•  Competency 
Development 

•  Competency 
Analysis 

•  Workgroup 
Development 

•  Participatory 
Culture 

•  Competency 
Based  Practices 

•  Career 
Development 

•  Workforce 
Planning 

2 

Managed 

•  Training  and 
Development 

•  Communication 
and  Coordination 

•  Compensation 

•  Performance 
Management 

•  Work 
Environment 

•  Staffing 

Table  2:  People  CALM  Threads 


formance. 

•  Building  workgroups  and  culture. 

Improve  coordination  and  interac¬ 
tion  among  individuals  and  work¬ 
groups.  (The  term  workgroups  has 
replaced  the  term  teams  in  this  ver¬ 
sion  of  the  People  CMM.) 

•  Motivating  and  managing  perfor¬ 
mance.  Measure  and  develop  indi¬ 
vidual  performance;  align  that  per¬ 
formance  with  organizational  objec¬ 
tives. 

•  Shaping  the  workforce.  Evaluate 
current  workforce  practices,  individ¬ 
ual  capability  and  skills,  and  organiza¬ 
tional  needs  and  devise  plans  to 
address  the  gaps. 

PA  threads  may  allow  organizations 
to  follow  an  alternate  path  of  improve¬ 
ment.  For  example,  let  us  say  that  your 
organization  would  prefer  to  focus  on 
building  a  truly  competent  and  skilled 
workforce.  There  is  a  PA  thread  called 
Developing  Competency.  This  thread  begins 
at  Level  2  with  the  PA  Training  and 
Development.  It  focuses  on  preparing  an 
individual  to  improve  his  capability  to 
perform  his  immediate  assignments.  At 
Level  3  in  the  Developing  Competency 
thread,  we  come  to  Competency  Analysis. 
The  purpose  of  this  PA  is  to  identify  the 
knowledge ,  skills ,  and  process  abilities  required 
to  perform  the  organisation’s  business  activities 
so  that  they  may  be  developed  and  used  as  a 
basis  for  workforce  practices.  This  PA  focus¬ 
es  on  identifying  how  various  business 
areas  in  the  organization  currently  con¬ 
duct  business,  defining  the  processes 
used,  and  identifying  any  commonalities 
or  gaps,  in  order  to  fulfill  not  only  cur¬ 
rent  business  needs,  but  future  business 
needs  as  well.  The  next  PA  in  this  PA 
thread  is  Competency  Development. 


Competency  Development  provides 
organizational  opportunities  to  work¬ 
force  personnel  to  improve  their  individ¬ 
ual  capability,  and  thus,  the  capability  of 
the  organization.  As  the  maturity  levels 
increase,  so  does  the  sophistication  of 
the  organizational  concepts  introduced. 
Other  competencies  introduced  at  vari¬ 
ous  levels  in  various  PA  threads  include 
mentoring  (a  formal,  structured  effort) 
and  empowered  workgroups  (providing 
more  autonomy  to  workers,  freeing  them 
to  perform  their  tasks  with  less  supervi¬ 
sion,  and  freeing  their  managers  to  focus 
on  more  strategic  business  concerns). 

It  must  be  remembered,  however, 
that  the  best  way  to  achieve  lasting 
improvement  and  organizational  change 
is  to  implement  all  the  PAs  at  Level  2 
first,  and  then  continue  with  all  of  the 
PAs  at  Levels  3,  4,  and  5.  Selecting  a  path 
based  on  PA  threads  increases  the  risk  of 
not  fully  achieving  improvement  in  orga¬ 
nizational  capability.  If  you  look  at  the 
PA  discussed  as  examples  in  the  previous 
paragraph  (Training  and  Development  at 
Level  2  and  Competency  Analysis  and 
Competency  Development  at  Level  3), 
you  will  discover  relationships  or  links 
from  those  Level  3  PAs  back  to  the  Level 
2  PAs.  And  each  PA  that  resides  in  a 
maturity  level  also  has  interdependencies 
with  other  PAs  in  that  level.  Your  orga¬ 
nization  may  decide  to  select  one  PA 
thread  to  concentrate  on,  but  (because 
of  the  interdependencies  among  the  PAs 
within  its  own  level  and  outside  the  lev¬ 
els)  you  also  will  have  to  back  up  and 
pull  what  is  needed  from  the  PAs  outside 
the  thread  you  have  selected.  You  also 
cannot  pick  PAs  willy-nilly.  Even  when 
using  the  PAs  thread  concept,  you  must 
implement  the  PAs  within  Level  2  first, 


then  Level  3,  then  Level  4,  and  then 
Level  5. 

So  in  reality,  it  is  difficult  to  imple¬ 
ment  the  model  via  PA  threads  instead 
of  by  PAs  within  a  specific  maturity 
level. 

The  Most  Fundamental  Level 
to  Implement  (or  Bang  for 
the  Buck ) 

At  Maturity  Level  2  —  the  Managed  Level 
-  the  People  CMM  PAs  focus  on  instill¬ 
ing  basic  discipline  into  workforce  activ¬ 
ities  to  achieve  repeatability.  This  level  is 
the  most  fundamental  to  implement,  as 
it  is  the  basic  building  block  for  all  ensu¬ 
ing  levels. 

Level  2  consists  of  six  PAs.  The  PAs 
at  Level  2  are  the  following: 

•  Staffing.  Recruiting,  selecting,  and 
transitioning  people  into,  and  out  of, 
assignments. 

•  Communication  and  Coordina¬ 
tion.  Ensuring  timely  communica¬ 
tion  for  sharing  information  and 
coordinating  activities. 

•  Work  Environment.  Providing 
physical  working  conditions  and 
resources  to  enable  work  to  be  per¬ 
formed. 

•  Performance  Management.  Clear 
objectives  used  to  measure  and 
improve  unit  and  individual  perfor¬ 
mance. 

•  Training  and  Development.  En¬ 
suring  that  individuals  have  the  skills 
required  to  perform  their  assign¬ 
ments,  with  relevant  development 
opportunities  provided. 

•  Compensation.  Everybody’s  favor¬ 
ite  —  remuneration,  rewards,  and  ben¬ 
efits  based  on  contribution  and  value 
to  the  organization. 

If  you  look  closely  at  just  the  names 
of  the  PAs,  you  will  probably  draw  the 
conclusion  that  these  are  the  processes 
that  need  to  be  implemented  to  provide 
incentives  for  people  to  join  your  organiza¬ 
tion  and  then,  to  actually  stay  there.  You 
will  also  notice  that  these  are  the  areas 
that  will  most  likely  motivate  your 
employees,  offer  them  career  opportuni¬ 
ties,  and  provide  them  with  an  infrastruc¬ 
ture  that  supports  them  in  doing  their 
work  with  the  least  amount  of  hassle. 

You  may  also  be  saying,  Hey  —  Tevel  2 
looks  a  lot  like  my  organisation’s  human 
resources  department.  I  don’t  work  there,  so  I 
guess  the  People  CMM  is  not  my  problem. 
Well,  maybe  —  maybe  not.  It  is  true  that 
in  the  People  CMM,  the  process  owners1 
of  Maturity  level  2  are  Human 
Resources  (HR)  personnel.  But  just 
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because  HR  owns  the  Level  2  processes, 
ownership  does  not  mean  that  they  (HR) 
are  the  only  ones  affected  by  the 
processes  and  are  the  only  ones  that  have 
to  worry  about  the  processes.  HR  pro¬ 
fessionals  have  stressed  that  a  program 
based  on  the  People  CMM  model  should 
not  be  treated  as  just  an  HR  initiative  [3]. 
Good  People  CMM  implementation 
means  that  individuals,  teams,  and  man¬ 
agement  share  commitment  and  respon¬ 
sibility  [4].  And  after  all,  HR  policies  are 
designed  for  —  and  affect  —  the  entire 
workforce. 

The  remaining  three  maturity  levels 
contain  more  advanced  practices  and 
basically  build  on  the  foundation  laid  at 
Level  2.  At  the  higher  maturity  levels, 
more  people  from  different  areas  in  the 
organization  get  involved  in  People 
CMM-based  process  improvement, 
process  ownership  becomes  more  dis¬ 
persed  throughout  the  organization  (not 
just  HR),  and  interactions  among  HR, 
line  management,  individuals,  and  work¬ 
groups  increase.  So,  implementing  the 
People  CMM  is  not  just  an  HR  effort. 

The  People  CMM  as  Problem 
Solver 

Looking  again  at  Maturity  Level  2,  the 
People  CMM  can  improve  an  organiza¬ 
tion’s  ability  to  attract,  develop,  and 
retain  individuals  through  such  PAs  as 
staffing,  communication  and  coordina¬ 
tion,  and  work  environment  (by  estab¬ 
lishing  an  environment  that  encourages 
people  to  join  the  organization,  sharing 
organizational  information  of  interest  to 
new  and  prospective  employees,  and 
ensuring  timely  job  offers  and  support¬ 
ive  recruiting  practices);  performance 
management  and  compensation  (by 
appropriately  evaluating  and  rewarding 
individual  performance);  and  training 
and  development  (by  motivating  person¬ 
nel  by  offering  ongoing  skills  develop¬ 
ment  and  personal  career  advancement). 
Instituting  these  PAs  appropriately 
makes  people  want  to  work  in  an  organi¬ 
zation.  If  people  do  not  want  to  work  in 
the  organization,  then  they  will  leave, 
and  the  organization’s  reputation  for 
being  a  bad  place  to  work  will  leak  out  to 
the  marketplace. 

As  part  of  classes  and  seminars,  the 
Software  Engineering  Institute  (SEI) 
collected  data  on  people  issues  that  orga¬ 
nizations  found  most  worrisome  [5].  In 
addition  to  the  problems  discussed 
above,  areas  of  concern  included  the  fol¬ 
lowing: 

•  Enabling  people  to  deal  with  contin¬ 


ual  change  in  the  organization. 

•  Changing  organizational  culture  by 
moving  to  a  team  culture. 

•  Ensuring  consistent  communication 
between  management  and  staff. 

•  Defining  roles  and  responsibilities. 

•  Aligning  personal  goals  with  organi¬ 
zational  goals  and  business  objec¬ 
tives. 

Briefly,  the  People  CMM  PAs  that 
address  these  issues  are  the  following  [5]: 

Enabling  people  to  deal  with  con¬ 
tinual  change  in  the  organization. 

Staffing  introduces  new  employees  into 
the  organization  in  an  orderly  manner, 

“You  cannot  expect  your 
employees  to  do  all  of 
the  extra  work  required 
to  participate  in  process 
improvement  activities 
perceived  to  be  of  no 
real  value  to  them,  or  to 
achieve  a  formal 
maturity  level ...  if 
your  employees 
feel  unappreciated, 
undervalued,  and 
abused ” 

Training  and  T)evelopment  orients  employ¬ 
ees  to  organizational  practices,  and 
Competency  Development  integrates  employ¬ 
ee  skills  with  organizational  competen¬ 
cies.  Overcoming  resistance  to  change  is 
addressed  by  practices  in  Communication 
and  Coordination  that  stresses  communi¬ 
cating  organizational  values  (including 
policies  and  procedures  related  to 
change)  and  expectations  of  managers 
and  employees,  and  Participatory  Culture 
empowers  employees  to  suggest  organi¬ 
zational  improvements  and  make  deci¬ 
sions  related  to  their  work. 

Changing  organizational  culture 
by  moving  to  a  team  culture  (remem¬ 
ber,  the  term  workgroups  replaces  the 
term  teams  in  this  version  of  the  People 
CMM).  Communication  and  Coordination 
communicates  organizational  values 
regarding  workgroups  and  identifies 


dependencies  to  be  coordinated  among 
them.  Participatory  Culture  and  Empowered 
Workgroups  empower  workgroups  to 
make  decisions  regarding  the  conduct  of 
their  work.  Competency-Pased  Practices 
defines  process  abilities  and  skills  that 
can  be  applied  to  workgroups,  and 
Workgroup  Development  identifies  opportu¬ 
nities  for  establishing  workgroups  and 
planning  work  around  those  groups. 

Ensuring  consistent  communica¬ 
tion  between  management  and  staff. 
Communication  and  Coordination  contains 
practices  that  encourage  the  formation 
of  communication  mechanisms  up, 
down,  and  across  the  organization. 
Performance  Management  uses  the  informa¬ 
tion  communicated  to  effectively  moni¬ 
tor  and  measure  individual  performance 
by  managers  and  employees,  and 
Participatory  Culture  uses  the  information 
communicated  to  allow  individuals  and 
workgroups  to  make  appropriate  deci¬ 
sions  related  to  their  work. 

Defining  roles  and  responsibili¬ 
ties.  Staffing  and  Competency  Analysis 
analyze  the  work  to  be  performed,  the 
knowledge,  skills,  and  process  abilities 
needed  to  perform  it,  and  map  roles  and 
responsibilities  to  the  work.  Training  and 
Development,  Career  Development,  and 
Competency  Development  ensure  that 
staff  can  perform  their  assigned  work,  as 
required  by  their  roles  and  responsibili¬ 
ties.  Participatory  Culture  defines  who 
may  make  decisions  under  what  circum¬ 
stances. 

Aligning  personal  goals  with  orga¬ 
nizational  goals  and  business  objec¬ 
tives.  Performance  Management  defines 
individual  performance  objectives. 
Communication  and  Coordination  pro¬ 
vides  information  about  organizational 
performance  to  individuals.  Perfor¬ 
mance  Management  and  Participatory 
Culture  provide  ongoing  feedback  to 
individuals  about  their  performance. 
Organizational  Performance  Alignment 
maps  performance  results  at  all  levels  to 
individual,  workgroup,  unit,  and  organi¬ 
zational  goals. 

Not  only  can  these  issues  result  in 
poor  workforce  performance,  they  can 
also  cause  process  improvement  efforts 
underway  in  organizations  to  stall  or  fail. 
Process  improvement  requires  some 
level  of  participation  from  most  of  your 
organization.  You  cannot  expect  your 
employees  to  do  all  of  the  extra  work 
required  to  participate  in  process 
improvement  activities  perceived  to  be 
of  no  real  value  to  them,  or  to  achieve  a 
formal  maturity  level  rating  to  keep  your 
organization  in  business,  if  your  employ- 
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ees  feel  unappreciated,  undervalued,  and 
abused.  People  will  see  that  the  only  real 
opportunity  offered  in  such  an  organiza¬ 
tion  is  to  leave.  And  they  will.  It  is  easier 
to  leave  than  stay  and  work  in  a  nasty 
place  that  only  cares  about  building  the 
business  and  not  building  its  people. 

Conclusion 

Why  should  we  use  the  People  CMM? 
Short  answer  —  using  the  People  CMM 
provides  a  structure  for  unstable  organi¬ 
zations  to  become  more  stable.  Has  your 
quest  for  a  CMMI  level  rating  stalled?  Is 
it  in  trouble?  There  are  many  potential 
reasons  for  the  problems  you  are 
encountering,  from  lack  of  management 
commitment  to  inadequate  resources 
and  funding  to  the  overcoming  of  resis¬ 
tance  to  change.  Organizations  have 
reported  that  when  their  CMM  or 
CMMI  efforts  ran  into  trouble,  concen¬ 
trating  on  the  lessons  from  the  People 
CMM  provided  enough  stability  and 
enough  guidance  for  organizational 
change  to  get  their  process  improvement 
efforts  back  on  track  [3,  4]. 

Other  organizations  that  have  been 
successful  in  implementing  the  CMMI 
continue  their  process  improvement 
journey  by  selecting  and  implementing 
the  People  CMM.  Based  on  their  success 
with  the  CMMI,  these  organizations  are 
concentrating  on  supporting  their  work¬ 
force  in  order  to  continue  successful 
CMMI  practice,  and  to  keep  their 
employees  excited  about  the  work  they 
are  doing.  These  organizations  see  the 
need  for  improving  the  capability,  not 
only  of  their  technical  processes,  but 
also  of  their  workforce  practices.  As 
such,  they  are  using  the  People  CMM  as 
their  guide  [6,  7]. 


A  very  smart  man  in  one  of  my  class¬ 
es  finished  his  presentation  as  follows: 

Why  should  me  use  the  CMM ?  because  CMM 

stands  for  Can  Make  Money. 

I  think  that  says  it  all.^ 
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Note 

1.  Process  ownership  may  reside  with  an 
individual,  group,  or  organization. 
Process  owners  coordinate  various 
activities  associated  with  process,  such  as 
writing  processes,  changing  processes, 
ensuring  that  processes  are  implemented 
in  an  organization,  and  acting  as  the  des¬ 
ignated  point  of  contact  for  process- 
related  information  and  activities. 
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Web  Sites 


Project  Smart 

www.projectsmart.co.uk 

Project  Smart  is  the  project  management  resource  that  helps 
managers  at  all  levels  to  improve  their  performance.  They  pro¬ 
vide  an  important  knowledge  base  for  those  involved  in  manag¬ 
ing  projects  of  all  kinds.  With  regular  updates,  Project  Smart 
keeps  you  up-to-date  with  the  latest  project  management  ideas. 

Joint  Program  Management  Handbook 

www.dau.mil/pubs/handbook/handbook.asp 
The  Joint  Program  Management  Handbook  provides  a  quick 
guide  to  assist  experienced  acquisition  professionals  assigned  to 
a  joint  acquisition  program.  It  offers  current  policy  and  advice 
on  joint  program  issues  related  to  service  responsibilities,  capa¬ 
bilities  and  requirements,  project  manager  authority,  and  fund¬ 


ing.  The  views  of  experienced  joint  program  managers  are  high¬ 
lighted  within  this  guide  to  give  practical  advice  to  the  reader. 
Lessons  learned  and  practical  guidelines  derived  from  Joint 
Working  Group  deliberations  (November  2003)  and  from 
Defense  Acquisition  University  faculty,  who  have  joint  program 
management  experience,  have  been  included. 

Project  Management  Library 

www.managementhelp.org 

The  library  provides  easy-to-access,  clutter-free,  comprehensive 
resources  regarding  the  leadership  and  management  of  yourself, 
other  individuals,  groups,  and  organizations.  Content  is  rele¬ 
vant  to  the  vast  majority  of  people  whether  they  are  in  large  or 
small  for-profit  or  nonprofit  organizations.  The  library  has  one 
of  the  world  s  largest  collections  of  these  resources. 
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Tools  for  Decision  Analysis  and  Resolution 


Dr.  Richard  D.  Stutzke  (late) 

Science  Applications  International  Corporation 

Engineers ■  managers ■  and  estimators  must  often  select  the  best  items from  a  large  list.  One  example  is  which  features  to  include 
in  a  product  or  system.  This  article  describes  two  types  of  decision-making  methods  to  help  do  this. 


Systems  integration  projects  require  that 
many  kinds  of  decisions  be  made,  as 
illustrated  in  Table  1.  The  evaluation  and 
selection  of  alternatives  is  often  difficult 
as  multiple  individuals  may  be  required  to 
reach  a  consensus  by  considering  one  or 
more  decision  factors. 

Making  any  decision  requires  time  and 
money.  Thus,  the  first  decision  should  be 
whether  the  issue  merits  the  use  of  a  for¬ 
mal  decision  method.  If  making  a  wrong 
decision  will  have  significant  impacts  for 
the  project,  then  the  team  should  use  a 
formal  decision  method.  Typical  criteria 
for  deciding  if  a  decision  is  significant  are 
cost,  delay,  safety,  and  corporate  liability. 
For  example,  if  a  particular  component 
contributes  50  percent  to  the  total  cost  of 
the  system,  then  careful  analysis  is  war¬ 
ranted. 

This  article  describes  two  types  of 
decision-making  methods:  voting  and 
multiple  criteria  decision-making.  Voting 
techniques  allow  a  group  to  rank  alterna¬ 
tives  based  on  unstated  criteria.  Multi- 
Criteria  Decision-Making  (MCDM)  tech¬ 
niques  allow  a  group  of  people  to  specifi¬ 
cally  identify  important  criteria  and  then 
combine  ratings  of  these  criteria  to  identi¬ 
fy  the  best  alternative.  These  methods  can 
easily  be  implemented  using  spreadsheets. 

Voting  Techniques 

Voting  techniques  provide  a  way  to  rank  a 
set  of  alternatives.  Political  scientists  and 
game  theorists  have  studied  many  types  of 
voting.  Each  voting  scheme  has  particular 
advantages  and  disadvantages  with  respect 
to  various  criteria  such  as  fairness,  monot¬ 
onousness,  sensitivity  to  minor  changes  in 
the  way  the  votes  are  cast,  abstentions, 
insincerity,  and  susceptibility  to  manipula¬ 
tion. 

Approval  voting  allows  each  voter  to 
vote  for  (or  approve  of)  as  many  items  as 
he  or  she  desires;  however,  each  voter  can 
cast  only  one  vote  for  each  item.  The  item 
with  the  most  votes  wins.  (Alternatively,  N 
items  having  the  largest  numbers  of  votes 
may  win.)  Approval  voting  is  simple  to 
understand  and  use.  Many  governments 
and  organizations  around  the  world  use  it 
to  elect  officials. 


Table  2  shows  an  example  of  approval 
voting  used  to  select  features  from  a  list  of 
five  features,  here  identified  as  A  through 
E.  There  are  five  voters  (stakeholders) 
whose  votes  are  shown  by  the  Xs  in  the 
table.  The  right-hand  column  shows  the 
total  votes  received  by  each  feature. 
Feature  D  is  the  winner,  with  feature  B  the 
second  choice. 

The  bottom  row  of  the  table  shows 
the  total  votes  cast  by  each  voter.  The 
number  of  votes  cast  varies,  perhaps 
indicating  that  the  stakeholders  did  not 
carefully  consider  their  choices  and  so 
the  result  may  not  truly  represent  the 
best  consensus.  To  obtain  a  better  result, 
use  techniques  that  require  the  voters  to 
make  a  standardised  commitment  and  so 
improve  the  sampling  of  the  stakehold¬ 
ers.  Two  ways  to  do  this  are  the  nominal 
group  technique  and  multi- voting. 

The  Nominal  Group  Technique  produces 
a  consensus  of  rankings.  Assume  that  the 
number  of  items  in  the  list  is  L.  Allow 
each  person  to  choose  N  items,  where  N 
is  approximately  the  total  number  of 
items  desired  on  the  final  list.  (Choosing  a 


value  of  N  that  is  less  than  the  final  num¬ 
ber  of  items  desired  will  force  the  stake¬ 
holders  to  make  careful  decisions.)  Each 
person  must  select  the  N  most  important 
items,  ranking  them  from  N  (most  impor¬ 
tant)  to  1  least  important.  (This  is  a  good 
ranking  system,  since  the  items  receiving 
no  votes  will  have  a  zero  score.  Scoring 
would  be  more  complicated  if  1  denoted 
the  most  important  item.)  The  facilitator 

Table  1 :  Typical  Decisions  for  Systems 
Integration  Projects 

•  Choose  product  features 

(with/without  other  constraints). _ 

•  Identify  the  best  design  option  (trade 

studies). _ 

•  Decide  whether  to  make,  reuse,  or 

buy. _ 

•  Select  a  Commercial-off-the-Shelf 

(COTS)  component  or  tool. _ 

•  Pick  a  vendor  or  subcontractor. _ 

•  Select  a  risk  mitigation  approach. 

•  Decide  to  bid  or  not  to  bid. _ 

•  Terminate  integration  testing. _ 

•  Modify  work  products  that  are 
already  baselined. 


Table  2:  Approval  Noting  Example 


Feature 

Stakeholders 

Total  Votes 

1 

2 

3 

4 

5 

A 

X 

1 

B 

X 

X 

X 

3 

C 

0 

D 

X 

X 

X 

X 

X 

5 

E 

X 

1 

Total  Votes  By  Voter 

2 

3 

2 

1 

2 

Table  3:  Nominal  Group  Technique  Example 


Feature 

Stakeholder 

Total  Votes 

1 

2 

3 

4 

5 

A 

1 

2 

2 

5 

B 

3 

2 

3 

3 

3 

14 

C 

0 

D 

2 

3 

1 

2 

1 

9 

E 

1 

1 

2 
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Feature 

Stakeholder 

Total 

Rank 

1 

2 

3 

4 

5 

6 

Votes 

A 

0 

- 

B 

3 

1 

1 

1 

1 

7 

1 

C 

1 

1 

1 

3 

3 

D 

1 

2 

3 

4 

E 

1 

1 

1 

1 

4 

2 

F 

0 

- 

G 

1 

1 

5 

H 

0 

- 

Total  Votes  Cast 

3 

3 

3 

3 

3 

3 

Table  4:  Example  of  Multivoting 


Total  Votes 
Received 


8 

7 

6 

5 

4 

3 

2 

1 

0 


2  3  4  5 

Rank 


Figure  1 :  Pareto  Ranking  of  the  Scores 


|  Strongly  Disagree 

Disagree 

Neutral 

Agree 

Strongly  Agree 

|  Never 

Seldom 

Sometimes 

Often 

Always 

|  Hourly 

Daily 

Weekly 

Monthly 

[Yearly 

Table  5:  Some  Preference  Ratings  (Likert  Scales j  [1] 


collects  the  votes  and  totals  the  votes  for 
each  item.  The  item  with  the  largest  total 
wins. 

Table  3  (see  previous  page)  shows  an 
example  of  five  features  (A  through  E) 
with  five  stakeholders  (1  through  5). 
Each  stakeholder  was  allowed  to  choose 
and  rank  the  three  most  important  items. 
The  last  column  shows  the  total  score. 
Feature  B  is  best,  with  Feature  D  ranked 
second. 

In  multi-votings  each  stakeholder  has  a 


Table  6:  Some  Preference  Ratings  (Likert 
Scales j 


Very  Low 

<  four  months 

Low 

>  four  months  and  <  one  year 

Nominal 

>  one  year  and  <  three  years 

High 

>  three  years  and  <  six  years 

Very  High 

>  six  years 

certain  number  of  votes,  N,  to  cast  as  he 
or  she  likes.  A  stakeholder  can  cast  one, 
two,  or  even  all  N  votes  for  a  single  item. 
Table  4  shows  an  example  of  eight  fea¬ 
tures  (A  through  H)  and  six  voters 
(stakeholders).  Each  voter  is  given  three 
votes  to  cast.  The  table  shows  the  total 
votes  for  each  feature  and  ranks  the  fea¬ 
tures  based  on  these  totals.  Feature  B  is 
ranked  first.  Feature  E  is  ranked  second. 
Features  C  and  D  have  the  same  total 
score,  but  Feature  C  was  selected  for 
third  place  because  three  stakeholders 
voted  for  it  while  only  two  voted  for 
Feature  D. 

Pareto  histograms  help  one  to  visual¬ 
ize  the  strength  of  the  stakeholders’ 
preferences.  Figure  1  shows  the  scores 
for  each  item  arranged  in  descending 
order.  Feature  B  is  clearly  preferred. 
Features  E,  C,  and  D  are  close  in  value.  A 


change  of  one  vote  from  E  to  C  (or  D) 
would  cause  C  (or  D)  to  move  into  sec¬ 
ond  place.  Feature  G  is  a  distant  fifth  and 
is  only  one  vote  away  from  obscurity 
(with  Features  A,  F,  and  H). 

These  methods  can  be  used  iterative¬ 
ly.  The  group  can  vote  on  a  set  of  alter¬ 
natives  and  then  eliminate  the  items  hav¬ 
ing  the  fewest  votes.  Optionally,  they  can 
discuss  the  top  few  items  and  revise  the 
item  descriptions.  Then  they  repeat  the 
process  with  the  revised  list. 

Techniques  for  Handling 
Multiple  Criteria 

Estimation  often  involves  ranking 
objects  based  upon  multiple  criteria.  For 
example,  due  to  limited  resources,  one 
might  need  to  choose  which  set  of  tasks 
is  the  most  important  to  implement,  or 
which  design  is  the  best  among  a  set  of 
possible  designs. 

The  stakeholders  may  also  be 
involved  in  determining  the  value  or  util¬ 
ity  of  a  particular  product  or  process. 
Often,  the  value,  or  benefit,  depends  on 
many  subjective  factors  that  are  difficult 
to  quantify.  The  academic  discipline  of 
decision-making  deals  with  models  (nor¬ 
mative  models)  that  help  associate  and 
measure  such  factors.  The  two  main 
types  of  models  are  expected  utility  theory 
and  multi- attribute  utility  theory  (MAUT). 

In  expected  utility  theory ,  the  value  of  a 
particular  outcome  is  determined  by  esti¬ 
mating  the  probability  of  that  outcome 
and  multiplying  it  by  the  estimated  utility 
of  that  outcome.  The  probability  and 
utility  are  expressed  as  real  numbers.  For 
example,  suppose  that  a  lottery  ticket  is 
purchased  for  $5.00.  If  the  ticket  is  a 
winner,  the  ticket  holder  will  receive 
$10,000.  If  the  chance  of  winning  the 
lottery  is  one  in  one  million,  however, 
the  expected  return  is  only  $0.01  (=  10'6 
x  104).  In  this  case,  the  expected  return 
does  not  justify  the  price  of  the  ticket. 
Quantitative  risk  assessment  is  based  on 
utility  theory.  Specifically,  the  risk  impact 
equals  the  probability  of  occurrence 
times  the  cost  of  occurrence. 

MAUT  extends  expected  utility  theo¬ 
ry  to  decisions  with  multiple  alternatives 
that  depend  on  many  attributes  or  crite¬ 
ria.  MAUT  maximizes  a  function  of  the 
various  criteria,  and  it  assumes  that  one 
criterion  can  counterbalance  another 
(substitution).  For  example,  cost  reduc¬ 
tions  or  revenue  increases  can  offset 
investment  or  implementation  costs.  To 
define  a  MAUT  technique,  consider  two 
things:  how  the  properties  map  to  an 
appropriate  measurement  scale  that  pre- 
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Factor  Name 

Weight 

Ratings 

8 

Functionality 

0.30 

VL 

LO 

NM 

HI 

VH 

9 

Integration  Effort  (person-weeks) 

0.20 

1 

2 

3 

4 

5 

10 

Cost  (dollars) 

0.20 

below  500 

500  to  1000 

above  1000 

11 

Vendor  Reputation 

0.10 

Poor 

Unknown 

Good 

Excellent 

12 

Product  Maturity 

0.10 

VL 

LO 

NM 

HI 

VH 

13 

Developer  Toolkit  available 

0.05 

No 

Yes 

14 

Training  availability 

0.05 

No 

Some 

Full 

15 

0.00 

16 

17 

Factor  Name 

Values 

18 

Functionality 

1.00 

2.00 

3.00 

4.00 

5.00 

19 

Integration  Effort  (person-weeks) 

1.00 

2.00 

3.00 

4.00 

5.00 

20 

Cost  (dollars) 

1.00 

0.00 

-1.00 

21 

Vendor  Reputation 

-5.00 

-3.00 

0.00 

9.00 

22 

Product  Maturity 

1.00 

2.00 

3.00 

4.00 

5.00 

23 

Developer  Toolkit  available 

0.00 

1.00 

24 

Training  availability 

1.00 

2.00 

3.00 

25 

Table  7:  User-Specified  Criteria  and  Weights 


A 

5_ 1 

1  C  1 

1_ D_ 1 

1  E 

1 

Description: 

Evaluation  of  Four  COTS  products 

2 

Prepared  By: 

Mary  Smith 

3 

Date  Prepared: 

1 4-Oct-04 

4 

5 

Option  = 

A 

B 

c 

D 

6 

Score  = 

1.80 

1.30 

1.75 

2.30 

7 

Factor 

8 

Functionality 

HI 

NM 

LO 

VH 

9 

Integration  Effort  (person-weeks) 

1 

2 

3 

4 

10 

Cost  (dollars) 

500  to  1000 

below  500 

500  to  1000 

above  1000 

11 

Vendor  Reputation 

Good 

Poor 

Good 

Unknown 

12 

Product  Maturity 

NM 

LO 

HI 

NM 

13 

Developer  Toolkit  available 

No 

Yes 

No 

Yes 

14 

Training  availability 

Some 

No 

Full 

Full 

15 

Table  8:  Weighted  Scores  for  the  COTS  Components 


serves  the  relations  between  the  objects1 
or  how  orthogonal  properties  (those 
with  no  overlap  in  what  each  measures) 
are  selected,  and  how  to  define  the  par¬ 
ticular  function  to  maximize.  A  related 
issue  is  defining  how  to  estimate  the 
function’s  parameters  (e.g.,  the  weights 
that  are  used  to  combine  ratings  for  dif¬ 
ferent  criteria). 

MAUT  techniques  use  preference  rat¬ 
ings,  illustrated  in  Table  5,  which  are 
ordinal  measurements.  The  ordinal  scale 
only  allows  comparisons  and  equality.  A 
restricted  ordinal  scale  that  places  objects 
into  bins  may  also  be  defined.  Table  6 
illustrates  such  a  scheme.  Many  paramet¬ 
ric  estimation  models  use  such  rating 
scales. 

To  use  MAUT  do  the  following: 

1.  Determine  a  measurement  scale  for 
each  attribute,  Ri. 

2.  Map  the  rating,  Ri,  to  a  (ratio  scale) 
value,  Vi. 

3.  Specify  the  relative  weights  of  the 
attributes,  Wi. 

Then  compute  the  score  using  the 
weighted  sum  of  the  values2.  For  exam¬ 
ple,  suppose  that  one  wants  to  evaluate 
four  COTS  components,  named  A,  B,  C, 
and  D.  (This  example  comes  from 
Section  27.5  in  [2].)  One  will  want  to 
consider  the  following  factors: 

1 .  Functionality. 

2.  Integration  Effort  (person-weeks). 

3.  Cost  (dollars). 

4.  Vendor  Reputation. 

5.  Product  Maturity. 

6.  Developer  Toolkit  Available. 

7.  Training  Availability. 

The  top  half  of  Table  7  lists  the  rat¬ 
ing  scale  for  each  factor  and  its  relative 
weight.  (The  weights  sum  to  1.0,  but  this 
is  not  necessary.)  The  bottom  half  of 
Table  7  shows  the  (ratio  scale)  values 
assigned  to  each  rating.  Table  8  shows 
the  evaluator’s  ratings  for  each  factor  for 
each  component,  with  the  total  weighted 
score  shown  in  row  6.  Component  D  is 
the  best,  with  Components  A  and  C 
nearly  tied  for  second  place. 

The  Analytic  Hierarchy  Process  (AHP)  is 
a  popular  MAUT  technique  developed 
by  Thomas  Saaty  [3].  AHP  addresses 
multiple  criteria,  including  subjective  cri¬ 
teria.  AHP  constructs  a  multi-level  hier¬ 
archy,  such  as  the  one  shown  in  Figure  2. 
The  top  level  is  the  decision  objective. 
The  bottom  level  (the  leaves)  is  the  pos¬ 
sible  actions  or  alternatives.  The  interme¬ 
diate  levels  represent  factors  that  affect 
the  preference  or  desirability  of  one 
alternative,  or  sub  factors  that  contribute 
to  a  factor. 

The  steps  of  the  AHP  process  are  the 


following: 

1.  Define  the  Problem. 

2.  Construct  the  Hierarchy. 

3.  Establish  Element  Comparisons. 

4.  Calculate  Element  Priorities. 

5.  Calculate  Overall  Priorities. 

The  decision-maker  identifies  which 
factors  are  important  and  defines  how 
they  influence  one  another.  Then  evalua¬ 
tors  make  pair-wise  comparisons  at  each 
level,  capturing  these  in  judgment  matrices , 
one  for  each  criterion  or  alternative.  The 
rating  matrix  is  triangular  since  comple¬ 


mentarities  are  assumed.  That  is,  if  A  >> 
B  then  B  <<  A.  If  Aj  denotes  the  rating 
of  object  i  relative  to  object  j  for 
attribute  A,  the  AHP  model  assumes 
that:  Aji  =  1/Aj.  Since  an  object  is  identi¬ 
cal  (equal)  to  itself,  A*  =  1.  For  a  single 
criterion  having  N  alternatives,  the  evalu¬ 
ator  must  make  N*(N  —  l)/2  compar¬ 
isons.  Saaty  uses  a  nine-value  preference 
scale.  (Other  rating  scales  can  be  used  if 
desired.) 

AHP  uses  matrix  calculations  to 
determine  the  preference  ratios  for 


Figure  2:  A  Hierarchy  for  Technology  Investment 
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objects  and  the  importance  ratios  (rela¬ 
tive  weights)  for  the  criteria  at  one  level 
(expressed  as  a  priority  vector).  There  are 
several  ways  to  calculate  the  priority  vec¬ 
tor.  Saaty  computes  matrix  eigenvalues. 
Eduardo  Miranda  uses  a  geometric  mean 
for  a  single  criterion  (software  size)  in 
[4].  The  calculations  in  Step  5  usually 
include  consistency  tests,  allowing  plan¬ 
ners  to  revise  their  relative  comparisons 
to  be  more  realistic  (i.e.,  they  repeat  Step 
4).  Then  the  AHP  model  combines  the 
relative  weights  to  obtain  a  ranked  list  of 
alternatives  (a  ratio  scale  preference  vec¬ 
tor). 

Summary 

This  article  describes  simple  techniques 
for  ranking  and  selecting  items,  as  well  as 
ways  to  evaluate  alternatives  based  on 
multiple  attributes.  These  techniques  all 
assume  rational  behavior  on  the  part  of 
the  participants.  Challenges  in  applying 
such  techniques  in  practice  are  the  fol¬ 
lowing: 

•  People  do  not  always  make  perfect 
decisions  (due  to  ignorance,  biases,  or 
manipulative  s  trategie  s) . 

•  People  may  change  their  minds. 

•  There  may  not  be  enough  resources 
(time,  money)  to  assign  good  ratings 
to  all  the  factors  identified. 

•  Key  factors  that  greatly  affect  the 
desirability  of  the  alternatives  may 
not  be  identified  (e.g.,  the  unexpected 
discovery  of  an  endangered  species 
residing  on  the  project  construction 
site). 

•  It  may  be  difficult  to  identify  orthog¬ 
onal  criteria.  ♦ 

Recommended  Reading 

For  additional  information  about  all  of 
these  techniques,  including  many  refer¬ 
ences,  see  Chapter  27  of  [2]. 

Part  III  of  [5]  is  a  good  place  to  start 
when  evaluating  the  economic  value  of 
products  and  systems.  Part  IIIA  deals 


with  cost-effectiveness  analysis.  Part  IIIB 
discusses  multiple-goal  decision  analysis. 
Part  IIIC  discusses  uncertainties,  risk, 
and  the  value  of  information.  Boehm 
specifically  addresses  quantities  of  inter¬ 
est  to  software  and  system  engineering. 

The  business  community  has  exten¬ 
sively  studied  decisions  involving  finan¬ 
cial  analysis.  Two  references  that  address 
software-related  business  decisions  are 
“Return  on  Software:  Maximizing  the 
Return  on  Your  Software  Investment”  by 
Steve  Tockey  [6]  and  “Making  a  Business 
Case:  Improvement  by  the  Numbers”  by 
Donald  J.  Reifer  [7]. 
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Notes 

1.  Measurement  assigns  directly 
observed  (or  estimated)  values  of 
some  attribute  to  a  mathematical  rep¬ 
resentation  that  preserves  the  relation¬ 
ships  between  the  objects  in  the  real 
world.  This  guarantees  that  the  math¬ 


ematical  objects  can  be  manipulated 
and  valid  conclusions  about  the  corre¬ 
sponding  real-world  objects  drawn.  A 
measurement  scale  defines  a  represen¬ 
tation  and  a  set  of  allowed  operations 
on  the  objects. 

2.  This  is  a  linear  function.  This  is  the 
usual  approach,  but  the  MAUT  tech¬ 
nique  also  works  with  a  non-linear 
objective  function. 
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Letter  to  the  Editor 


Dear  CROSSTALK  Editor, 

I  very  much  liked  the  theme  of  your  August  2007  issue  Stories  of 
Change  and  the  change  articles.  Great  topic  and  one  I  don’t  recall 
seeing  before.  It  was  a  good  reminder  that  implementing 
change  is  not  simple  but  it  can  be  managed  successfully.  I  par¬ 
ticularly  liked  the  article  Good  News  From  Iraq.  If  change  can  be 
successful  in  that  environment,  what  excuse  can  the  rest  of  us 
have  for  failing? 

I  would  like  to  add  one  point  about  resistance  to  change, 
and  that  is  trying  to  do  too  much  change  at  one  time.  People 
can  simply  be  on  overload  even  if  they  desire  the  change.  Case 


in  point:  In  the  mid- 9 0s,  my  base  was  undergoing  a  base  realign¬ 
ment  and  closure  process,  we  did  a  reorganization  to  a  matrix- 
type  organization,  and  we  were  downsizing.  Three  big  changes 
all  at  once!  Any  one  of  them  by  itself  would  have  been  a  chal¬ 
lenge.  A  word  to  the  wise:  Too  much  change  at  once  is  too  con¬ 
fusing,  especially  if  your  people  are  already  on  overload. 

Keep  those  CROSSTALK  issues  coming! 

—  Alan  Kaniss 
United  States  Navy 
<  alan.  kanis  s  @navy.mil> 
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Common  Misconceptions  About 
Service-Oriented  Architecture 


Grace  A.  Lewis,  Edwin  Morris,  Dr.  Dennis  B.  Smith,  Soumya  Simanta,  and  Lutz  Wrage 

Software  Engineering  Institute 

Service-Oriented  Architecture  (SOA)  is  having  a  major  impact  on  the  acquisition  and  development  of  software  systems 
because  of  its  potential  for  increased  business  agility,  adaptability  of  applications,  interoperability  between  systems,  and  reuse 
of  legacy  assets.  However,  organisations  often  make  decisions  on  SOA  adoption  without  carefully  analysing  the  implications 
of  their  decisions.  This  article  outlines  a  set  of  common  misconceptions  about  SOA  and  suggests  ways  to  more  effectively 
address  critical  SOA  issues  that  potential  users,  developers,  and  acquisition  officers  may  have. 


You  do  not  have  to  look  far  to  become 
aware  of  the  effect  that  SOA  is  hav¬ 
ing  on  software  systems.  Vendors  are 
aggressively  marketing  hardware,  soft¬ 
ware,  tools,  and  services  that  support  SOA 
implementation  within  organizations  as 
diverse  as  the  Department  of  Defense 
(DoD),  banks,  federal  agencies,  manufac¬ 
turing  companies,  and  health  care 
providers.  Even  more  significantly,  cus¬ 
tomers  are  embracing  SOA  with  the  goal 
of  reaching  a  previously  unachievable 
level  of  interoperability  among  systems 
and  agility  in  business  practices. 

SOA  may  currently  be  the  best  avail¬ 
able  solution  for  achieving  interoperabili¬ 
ty  and  agility,  as  well  as  providing  a  tech¬ 
nology  upgrade  path  that  preserves  the 
investment  in  legacy  systems  and  simpli¬ 
fies  deployment  of  new  systems. 
However,  our  experience  from  working 
with  customers  considering  the  adoption 
of  SOA  suggests  that  they  often  have  a 
variety  of  misconceptions  that  lead  them 
to  greatly  underestimate  the  effort 
required  to  successfully  implement  SOA. 
These  misconceptions  are  dangerous 
because  they  make  organizations  more 
susceptible  to  vendor  advertising  and 
hype.  In  addition,  these  misconceptions 
are  often  embraced  by  internal  IT  organi¬ 
zations,  leading  them  to  over-promise 
new  capabilities,  while  underestimating 
the  cost  and  effort  required  for  achieving 
even  modest  improvements.  Although 
some  of  these  common  misconceptions 
also  apply  to  traditional  single  systems,  we 
focus  on  their  relevance  to  SOA-based 
systems. 

We  hope  that  by  recognizing  these 
misconceptions,  organizations  can  better 
understand  and  evaluate  the  promises  of 
vendors  and  improve  their  own  internal 
SOA  expectations  and  planning  processes. 

Basic  SOA  Concepts 

SOA  is  a  way  of  designing  systems  com¬ 
posed  of  services  that  are  invoked  in  a  stan¬ 
dard  way.  As  an  architectural  style,  SOA  is 
neither  a  system  architecture  nor  a  com¬ 


plete  system.  An  SOA-based  system  is 
composed  of  the  following: 

•  Services  that  are  reusable  components 
that  represent  business  or  mission 
tasks,  such  as  customer  lookup,  weath¬ 
er,  sensor  placement,  account  lookup, 
or  credit  card  validation. 

•  Service  consumers  that  are  clients  for 
the  functionality  provided  by  the  ser¬ 
vices,  such  as  end-user  applications, 
systems,  or  even  other  services. 

•  SOA  infrastructure  that  connects  ser¬ 
vice  consumers  to  services. 

The  most  common  approach  to  SOA 
implementation  is  that  of  Web  services, 
which  relies  on  common  standards  that 
include  HTTP,  SOAP,  WSDL,  and  UDDI. 
However,  other  SOA-based  systems  can 
be  implemented  using  such  technologies 
as  MOM,  IBM  WebSphere  MQ,  publish- 
subscribe  systems  such  as  JMS,  and 
CORBA. 

Some  SOA  Misconceptions 

Seven  common  misconceptions  are  iden¬ 
tified  in  the  following  subsections.  The 
subsection  heading  represents  a  statement 
in  the  form  that  an  organization  might 
express  it.  The  body  of  each  subsection 
discusses  why  the  statement  expressed  in 
the  heading  can  be  misleading.  It  also  pro¬ 
vides  advice  on  how  to  avoid  falling  into 
common  traps. 

SOA  Provides  the  Complete 
Architecture  for  a  System 

Chief  among  SOA  misconceptions  is  the 
belief  that  simply  by  adopting  an  SOA 
strategy  for  the  enterprise,  an  organization 
has  established  a  complete  well-crafted 
architecture  that  will  help  the  organization 
achieve  its  IT  goals.  In  reality,  SOA  is  not 
an  architecture,  but  an  architectural  pat¬ 
tern  from  which  a  number  of  specific 
architectures  can  be  derived  -  both  good 
and  bad.  An  architectural  pattern  provides 
guidance  to  an  architect  that  enables  lever¬ 
aging  best  practices  for  that  specific  pat¬ 
tern.  It  defines  a  set  of  element  types,  a 
topological  layout  of  the  elements  that 


shows  their  relationships,  semantic  con¬ 
straints  on  elements,  and  interaction 
mechanisms  [1].  For  example,  the  ele¬ 
ments  in  the  SOA  pattern  include  service 
consumers,  service  descriptions,  service 
implementations,  and  possibly  a  service 
bus.  One  relationship  is  that  between  ser¬ 
vice  providers  and  service  consumers.  In 
the  case  of  Web  Services,  consumers  and 
services  are  connected  by  HTTP  or 
HTTPS  connectors  carrying  SOAP  mes¬ 
sages.  Given  the  architectural  elements,  or 
building  blocks,  any  number  of  systems 
can  be  developed  based  on  this  architec¬ 
tural  pattern.  These  concrete  elements  and 
their  interactions  are  the  architecture  of 
the  system. 

The  misconception  that  SOA  provides 
a  complete  architecture  also  leads  cus¬ 
tomers  to  believe  that  they  can  buy  SOA 
off  the  shelf.  Although  there  are  a  number 
of  products  available  in  the  marketplace 
that  can  help  an  enterprise  implement 
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SOA,  none  of  them  are  actually  an  imple¬ 
mentation  of  an  SOA-based  system. 
Software  architects  still  need  to  architect 
systems  based  on  the  SOA  architectural 
pattern.  They  have  to  design  services  and 
service  interactions  that  meet  the  quali¬ 
ties  that  stakeholders  expect  of  the  sys¬ 
tem.  In  addition,  the  architect(s)  must 
make  decisions  on  how  services  are 
implemented.  Service  implementations 
may  involve  developing  new  software, 
wrapping  a  legacy  software  system,  incor¬ 
porating  services  provided  by  third  par¬ 
ties,  or  a  combination  of  these  options. 

Information  about  the  quality  attrib¬ 
utes  of  SOA-based  software  systems  is 
just  beginning  to  become  available  in  the 
literature:  One  report  finds  that  SOA 
promotes  modifiability,  interoperability, 
and  extensibility,  but  can  have  a  negative 
impact  on  security,  performance,  testabil¬ 
ity,  and  auditability  [2].  For  a  given  sys¬ 
tem,  the  architect  needs  to  understand 
the  quality  attribute  requirements  and 
needs  to  architect  a  concrete  system 
around  the  tradeoffs  that  are  most 
important  to  the  stakeholders  of  the  sys¬ 
tem. 

All  Legacy  Systems  Can  Be  Easily 
Integrated  Into  an  SOA  Environment 

One  of  the  most  attractive  promises  of 
moving  towards  SOA  is  that  it  enables 
reusing  legacy  systems,  thereby  providing 
a  significant  return  on  the  investment  in 
these  systems.  However,  migrating  legacy 
systems  is  neither  automatic  nor  easy.  It 
might  not  make  business  or  technical 
sense  to  migrate  the  legacy  system  to  an 
SOA  environment. 

It  is  important  to  understand  technical 
constraints  of  the  legacy  components, 
such  as  immature  technology,  that  may 
require  significant  rework.  In  addition,  it  is 
necessary  to  understand  business  issues, 
such  as  the  business  case  that  will  justify 
the  migration  of  legacy  components  to 
services  in  the  specific  context.  An 
upfront  and  hands-on  analysis  of  techni¬ 
cal  feasibility  and  the  resultant  return  on 
investment  will  help  to  avoid  last-minute 
surprises. 

This  analysis  must  answer  at  least  the 
following  questions: 

1.  Have  consumers  for  the  services  been 
identified? 

2.  Is  it  technically  feasible  to  create  a  ser¬ 
vice  from  the  legacy  system  or  part  of 
the  system? 

3.  How  much  would  it  cost  to  expose 
services  from  the  legacy  system? 

4.  What  changes  will  have  to  be  made  to 
legacy  systems  in  order  to  use  these 
services? 


5.  How  much  will  these  changes  affect 
the  current  end  users  of  the  legacy  sys¬ 
tem  and  other  dependent  production 
systems? 

6.  Are  the  costs  of  exposing  services, 
together  with  the  associated  risks  of 
making  the  required  changes,  feasible 
from  a  business  perspective? 

The  bottom  line  is  that  there  are  issues 
to  take  into  consideration  that  go  beyond 
adding  a  service  interface  to  an  existing 
system. 

SOA  Is  All  About  Standards  and 
Standards  Are  All  That  Is  Needed 

This  statement  primarily  applies  in  the 
context  of  Web  services,  the  main  stan- 
dards-based  technology  available  today  to 
realize  SOA.  This  leads  to  a  corollary  mis¬ 
conception  that  SOA  and  Web  services 
are  the  same.  In  reality,  Web  services  are 
only  one  potential  approach  to  SOA 
implementation. 

It  is  true  that  public  standards  like 
those  supporting  Web  services  are  often 
preferable  to  proprietary  solutions 
because  they  are  (potentially)  supported 
by  a  wider  community.  But,  most  Web  ser¬ 
vice  standards  are  still  emerging  and  sub¬ 
ject  to  multiple  interpretations. 

Basic  infrastructure  standards  that 
support  the  exchange  of  messages 
between  service  consumer  and  provider- 
such  as  HTTP,  XML,  XML  Schema, 
SOAP,  WSDL,  and  UDDI  are  the  most 
developed  and  mature  of  the  Web  service 
standards.  However,  being  stable  for  years 
does  not  mean  that  the  standards  are  com¬ 
plete.  For  example,  after  adopting  basic 
infrastructure  Web  service  standards, 
some  organizations  found  that  their  ser¬ 
vices  still  could  not  communicate  infor¬ 
mation  effectively  with  other  services  due 
to  different  design  decisions  and  flexibili¬ 
ty  in  the  standards.  The  WS-I  Basic  Profile 
was  constructed  to  provide  better  interop¬ 
erability  across  implementations  using 
basic  infrastructure  standards  [3].  In  addi¬ 
tion,  revisions  to  standards  are  likely  in 
any  area  undergoing  rapid  advances  in 
technology. 

Standards  for  service  composition  (e.g. 
WSCL,  WS-Coordination,  BPEL,  and 
cross-cutting  standards  [e.g.  WS-Security, 
SAML,  WS-Transaction,  WS -Reliability]) 
are  less  mature  and  far  less  stable  than 
basic  infrastructure  standards.  Currently, 
there  are  a  number  of  competing  propos¬ 
als  and  standards  for  service  composition 
and  cross-cutting  concerns  that  conflict 
and  overlap.  Regarding  these  less  mature 
areas  of  Web  services,  the  old  saying  sums 
it  up  —  the  best  thing  about  standards  is  that 
there  are  so  many  to  choose  from. 


SOA  Is  All  About  Technology 

Vendors  pushing  SOA  products  will  (for 
good  reason)  promote  their  technologies 
as  the  solution  to  an  organization’s  IT 
problems.  However,  SOA  also  entails 
changes  to  the  organization’s  IT  gover¬ 
nance  model  —  the  set  of  rules  and  regula¬ 
tions  under  which  an  IT  department  oper¬ 
ates,  and  the  mechanisms  to  ensure  com¬ 
pliance  with  those  rules  and  regulations. 
This  is  especially  true  if  SOA  is  used  to 
support  business  processes  or  mission 
threads.  Therefore,  a  well-defined  gover¬ 
nance  model  that  includes  items  such  as 
the  following  is  essential  for  the  success  of 
SOA  implementation: 

•  Service  identification  that  maps  to 
business  or  mission  goals. 

•  Service  repository  management. 

•  Service  implementation  guidelines. 

•  Change  management  to  deployed  ser¬ 
vices. 

•  Mechanisms,  tools,  and  policies  for 
maintaining  and  monitoring  deployed 
services. 

•  Policy  enforcement  at  design  and  run 
time. 

•  Security  and  access  control. 

•  Definition  and  enforcement  of  SLAs 
between  service  consumers  and 
providers. 

The  implementation  of  SOA  in  an 
organization  should  be  part  of  a  larger 
effort  to  assure  that  SOA  and  related  gov¬ 
ernance  are  aligned  with  strategic  goals 
and  objectives. 

The  Use  of  Standards  Guarantees 
Interoperability  in  an  SOA 
Environment 

True  interoperability  can  only  be  achieved 
if  service  consumers  and  providers  inter¬ 
operate  at  both  the  syntactic  and  semantic 
levels.  There  is  interoperability  at  the  syn¬ 
tactic  level  if  they  can  exchange  raw  data 
elements  such  as  text,  numbers,  or  dates. 
There  is  interoperability  at  the  semantic 
level  if  they  understand  and  agree  on  the 
meaning  of  exchanged  data.  For  example, 
a  spacecraft  monitoring  application  may 
rely  on  a  service  that  does  an  analysis  of 
data  received  from  onboard  sensors.  The 
service  may  correctly  perform  the  analysis 
of  the  raw  temperature  data.  However,  it 
may  make  an  assumption  that  the  temper¬ 
ature  data  is  expressed  in  Celsius  as 
opposed  to  Fahrenheit.  In  such  a  case, 
there  is  interoperability  at  the  syntactic 
level,  but  not  at  the  semantic  level.  In  this 
example,  both  the  requesting  consumer 
and  the  onboard  sensor  share  a  common 
understanding  that  the  number  exchanged 
represents  temperature.  However,  there 
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must  also  be  a  deeper  understanding  of 
the  meaning  of  that  value,  such  as  the 
temperature  unit  or  where  and  how  it  was 
measured  [4].  The  results  of  an  incorrect 
assumption  in  this  case  could  prove  disas¬ 
trous  for  the  mission. 

In  the  case  of  Web  services,  for  ser¬ 
vice  consumers  and  providers  to  be  inter¬ 
operable  it  is  not  sufficient  to  agree  on  the 
representation  of  data  in  XML  documents 
because  there  is  no  way  to  specify  the 
meaning  of  data  in  an  XML  or  WSDL 
document  other  than  in  text  descriptions. 
The  problem  is  that  text  descriptions  are 
imprecise,  are  often  not  filled  in,  and  are 
not  readable  by  machines,  rendering  them 
open  to  multiple  interpretations  by  human 
developers.  Also,  even  though  the  full 
XML  Schema  Datatypes  specification  can 
be  used  to  specify  data,  it  is  rare  to  see 
anything  other  than  a  data  type  in  the 
WSDL  document  that  describes  Web  ser¬ 
vice  operations.  Optimal  methods  of 
describing  the  meaning  of  Web  service 
inputs  and  outputs  in  a  formal  manner  is 
still  an  area  of  active  research  [5,  6]. 

A  Service  Registry  Allows  Service 
Binding  Dynamically  at  Runtime 

Currently,  binding  to  services  is  usually 
done  at  design  time.  This  is  referred  to  as 
static  binding  or  fully-grounded  binding. 
Discovery  and  composition  of  services 
are  done  at  design  time  such  that  the 
developer  can  discover  the  syntax  and 
semantics  of  the  service  before  it  is  actu¬ 
ally  used.  In  the  case  of  dynamic  binding, 
discovery  and  composition  of  services  are 
done  at  runtime.  This  is  currently  a  com¬ 
plex  and  poorly  supported  task. 

In  a  basic  scenario  of  dynamic  bind¬ 
ing,  service  consumers  retrieve  the  service 
address  from  a  registry  before  each  call  to 
the  service.  If  there  are  several  providers 
of  the  same  service,  the  service  consumer 
can  choose  at  runtime  which  one  to  use. 
The  consumer  can  also  rank  providers 
based  on  quality  of  service  criteria, 
choose  a  preferred  provider,  and  use  oth¬ 
ers  as  backup  if  the  preferred  service  is 
not  available. 

More  advanced  automatic  discovery 
and  composition  of  new  services  at  run¬ 
time  requires  the  use  of  common  ontolo¬ 
gies  by  service  providers  and  consumers 
within  a  domain  to  describe  function  and 
usage  of  services.  Given  this  shared  ontol¬ 
ogy,  it  would  still  be  necessary  to  develop 
components  that  can  construct  the  right 
queries  for  the  discovery  of  services,  com¬ 
pose  services  when  there  is  not  a  single 
service  that  provides  the  needed  function, 
and  then  provide  the  right  data  to  invoke 
the  discovered  service.  Current  technolo¬ 


gies  have  not  advanced  to  a  point  where 
this  is  possible  in  production  environ¬ 
ments  [7]. 

Testing  SOA-Based  Systems  Is  No 
Different  Than  Testing  Any  Other 
Type  of  System 

Testing  service  consumers,  as  well  as  the 
services  themselves,  is  challenging  for  var¬ 
ious  reasons.  Most  traditional  testing  tech¬ 
niques  cannot  be  directly  applied  to  ser¬ 
vices  in  the  SOA  world  because  testing  has 
to  occur  at  runtime  and  in  real  time  [8]. 
Independent  testing  of  a  service  from  a 
service  provider  perspective  is  different 
from  that  of  a  service  consumer. 
Moreover,  the  service  provider  and  con- 


“Modeling  and 
simulation  can  provide 
some  guidance  and 
confidence  during  the 
design  phase ,  but  they 
are  not  a  substitution  for 
end-to-end  testing  of 
service-based 
applications.” 

sumer  must  collaborate  and  cooperate  to 
ensure  correctness  and  trustworthiness  of 
services  [8]. 

Service  consumers  can  only  be  fully 
tested  when  the  invoked  services  (or  test 
instances  of  them)  are  available.  The  ease 
of  testing  will  most  likely  depend  on 
whether  the  service  is  internal  or  external 
to  the  organization  —  there  is  more  control 
if  it  is  internal. 

In  an  SOA  environment  it  is  common 
for  different  services  to  be  owned  by  dif¬ 
ferent  organizations  and  for  services  to 
use  different  technologies.  Because  an 
SOA  environment  is  distributed,  loosely 
coupled,  and  asynchronous,  testing  can 
be  significantly  more  complex  than  sim¬ 
ply  testing  a  set  of  known  paths  in  a  sin¬ 
gle  system  [9].  Modeling  and  simulation 
can  provide  some  guidance  and  confi¬ 
dence  during  the  design  phase,  but  they 
are  not  a  substitution  for  end-to-end  test¬ 
ing  of  service-based  applications  [9]. 
Service  consumers  will  necessarily  have 
to  be  prepared  to  deal  (or  not  to  deal) 
with  degraded  service  modes  and  com¬ 
plete  service  failure. 


Services  can  be  reused  across  applica¬ 
tions  that  cross  enterprise  boundaries. 
Changes  requested  by  one  service  con¬ 
sumer  in  an  existing  service  can  result  in 
undesired  results  for  another  service  con¬ 
sumer.  Changes  in  service  interface  and 
implementation  must  be  tested  continu¬ 
ously  by  each  of  the  service  consumers  in 
order  to  ensure  that  the  actual  service 
behavior  conforms  to  intended  behavior. 
Finally,  service  providers  have  to  exten¬ 
sively  test  their  services  because  they  can¬ 
not  anticipate  all  the  possible  scenarios  in 
which  their  service  will  be  used.  Testing 
has  to  cover  functionality,  load  testing  and 
stress  testing,  as  well  as  other  elements 
specified  in  an  SLA. 

Conclusions 

We  believe  SOA  may  be  the  best  current 
approach  for  achieving  critical  interoper¬ 
ability,  agility,  and  reusability  goals  that  are 
common  to  many  organizations. 
However,  we  also  believe  that  the  difficult 
reality  of  building  and  managing  large- 
scale  SOA-based  systems  often  gets  lost  in 
the  understandable  corporate  desire  for 
sweeping  improvements  and  the  hype  of 
vendors. 

Our  intent  is  not  to  discourage  organi¬ 
zations  from  adopting  SOA,  but  to  cau¬ 
tion  them  about  some  important  issues 
and  risks  to  consider  while  creating  their 
SOA  strategy.  Most  of  these  issues  are 
currently  active  areas  of  research  in  the 
service-oriented  computing  community. 
The  solutions  will  require  time  to 
mature.  ♦ 
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SSMARTTeam  Management 


Want  to  skip  all  of  the  interesting  articles  this  month?  Then  use  this  Software  Technology  Support  Center  (STSC)  Statistical 
Management  Analysis  Response  Tool  (SSMART)  to  help  you  understand  how  teams  work.  All  you  need  is  a  single  die.  Cut  out 
the  tokens,  fill  in  with  your  team’s  name,  and  place  your  token  on  START.  Roll  your  die,  and  advance  the  number  you  roll.  Follow 
the  directions.  One  turn  per  player,  one  roll  per  turn. 


START 
Schedule  and 
budget  seem 
plentiful!  Roll 
the  die  and 
advance. 


Team  now 
works  for 
matrixed 
organization. 
Go  back  3. 


Total  team 
reorganization. 
Skip  1  turn, 
then  go  back 


Unexpected 
team  absences. 
Skip  1  turn. 


Team  and 
management 
read  Crosstalk 
regularly.  Go  to 


to  START. 


SUCCESS. 


Status  reports 
only  due 
monthly. 
Advance  3. 


Holding  weekly 
team  meetings. 
Go  ahead  2. 


Daily  team 
meetings  that 
last  10  minutes 
or  less.  Go 
ahead  1. 


Daily  team 
meetings  that 
drag  on  and  on. 
Go  back  to 
START. 


Team  lacks 
ability  to  set  their 
own  schedule. 
Sit  here  2  turns. 


Small  team  size. 
Go  ahead  4. 


Large  team  size. 
Skip  1  turn. 


Team  takes 
vacation. 
Return 

refreshed,  but 
go  back  2. 


Can’t  delete 
unachievable 
requirements. 
Sit  out  4  turns. 


Daily  status 
reports 
required. 
Go  back  6. 


Team  members 
added  late? 
Go  back  11 . 


Running 
short  of 
money.  Time 
for  team  party. 


SSMART 

STSC 

Statistical 

Management 

Analysis 

Response 

Tool 


Team  broken 
up?  Square  die 
and  go  back 
that  many. 


SUCCESS 
You’re  done! 
No  good  deed 
goes 

unpunished. 
Go  back  to 
beginning 
and  start 
over.  Repeat 
until 

retirement 

age. 


Team  lead 
multi-tasked 
to  other  projects. 
Skip  2  turns. 


Requirements 
re-scoped.  Roll 
twice,  multiply, 
and  go  back 
that  many. 


Earned  value 
metrics  ignored, 
schedule 
updated 
unrealistically. 
Skip  2  turns. 


No  team 
meetings. 
Go  back  6. 


New  reporting 
metrics 
required. 
Go  back  5. 


Replace  team 
lead.  Go  back  2 
squares  for 
each  time 
this  has 
occurred. 


New  team 
members  added 
late.  Roll  twice  and 
go  back  that  many. 


Forced  to  use 
new  and  untested 
tools.  Post 
resume,  skip 
1  turn. 


New  team 
members  added 
early. 

Go  ahead  1 . 


Weak  team 
leadership. 
Stay  here 
2  turns. 


Team  penalized  for 
setting  unrealistic 
schedule. 
Demotivated 
team  skips  2  turns. 


Team  squabble. 
Go  back  1  for 
each  day  team 
members  not 
speaking. 


Team 
No.  1 


Team 
No.  2 
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•  Automated  Tfest  Equipment  Software 
§  Engine  Test  Cells 


•  Industrial  Automation 

•  Application  Development 
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phil.perkinsfa:  tinker,  of.  mil 
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